[Kde-pim] KHolidays support for alternative calendar systems

[John Layt]

On Wednesday 20 January 2010 00:19:29 you wrote:
> > John Layt wrote:
> > Some of this will see a change in behaviour of KHolidays if not api/abi,
> > but with only 2 current clients I think the benefits outweigh the
> > disadvantages.
> 
> Would one of those you know about include KMyMoney 3.95svn? That has
> just started using HolidayRegion->isHoliday(date),
> HolidayRegion->isValid() and HolidayRegion::locations()
> 
> I am happy to work on the relevant changes required, if any are needed,
> to KMyMoney though.

Make that 3 then :-)  Actually I knew but forgot, it's one of the reasons I 
started poking away at this.  The changes are targeting 4.5 and won't break 
api/abi, so major changes won't be needed unless you want to use a new 
feature.

Which reminds me of another new API feature I was going to list, allowing apps 
to load their own holiday files if they had special requirements not met by 
the default set, e.g. a file of financial holidays for a particular bank or 
region or exchange.  (I know Allen has an idea listed in the design for a gui 
for users to set-up their own files, and for GHNS, this would be a stop-gap 
until then).

> > * Split the existing holiday files up into civil and religious files and
> > create a better naming scheme including country, language, region and
> > type.
> 
> So would that mean HolidayRegion::locations() (or the equivalent) could
> be passed an argument that means it will only return those locations
> that have holiday files of a particular type (e.g. civil)?

Hmmm, good idea, I'll steal that one :-)  I'll add that to the file metadata 
fields.  Any selection would be based on the metadata in the file and not on 
the file naming scheme.  Would we make it a strict rule not to mix types in a 
file?

> For religious files would they be named by faith and language only?

I think we would have to have 2 sets, a top-level or global faith/language 
set, then a region/faith/language set for local variations (where faith means 
a religion or any sub-set within that religion).  For the top-level the 
filename itself would just use a region code of xx which is the ISO code for 
supra-national groups.  So something like holiday_xx_es_catholic with a 
metadata display name of "Catholic (Spanish)" and holiday_ar_es_catholic with 
"Argentine Catholic (Spanish)".

The design actually has a nice directory based hierarchy for this, I'll have a 
think if we want to do that yet.

> > * Try sort out translation of the file names (I18N_NOOP the English names
> > in a file somewhere?).
> 
> Does KDE offer all the necessary methods to convert the file names
> without having to have a file somewhere? I presume it knows all
> languages and countries, but does it need to be taught about
> States/Islands/etc and faiths/religions?

I wouldn't be translating the file name per-se, but rather the metadata field 
inside the file.  There's only 2 ways to get strings translated in KDE, either 
include them in code somewhere, or in a .desktop file.  In this case the 
desktop file might be the way to go, as new holiday files could be added 
without changing any code.  However it's something I need to discuss with the 
translators first.

> Any plans to add a way of selecting holiday calendars to the KDE Control
> Module (Country/Region & Language)?

Yes, the thought had crossed my mind.  In particular, it might be useful once 
we allow them to choose to display multiple holiday files at the same time to 
know which is their 'official' holiday file for days-off to show in red, and 
if they select a second civil region to display those days-off won't be marked 
in red but in blue for information only.  But that might be a per-file 
setting, someone might want both sets of days off!  Some control over what 
colours are used will be needed too.  And...  

Well, I'll start to sort that out in the Plasma Calendar first, see what the 
use case is and if a shared config is needed.  But lets get the basics laid 
down first, them we can play with the user experience and feed that back into 
the library.

Cheers!

John.
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/