Yes, it works fine now as it is. Kind of.

Jan - can we close this ticket for now, and either re-open it or 
create new tickets if there are horde-specific date_holidays problems?

I added a few tickets fwiw:

http://pear.php.net/bugs/10220

http://pear.php.net/bugs/10221

http://pear.php.net/bugs/10222

I'll do as soon as I find the time.
Yes... Ok... I kept that in mind. Unfortunately, there doesn't seem to 
be a PEAR_DATA_DIR define, so going down from PEAR_INSTALL_DIR was my 
best chance. If I find a better solution (or anything changes within 
Date_Holidays), I'll send in another patch. Promise.

Are you still tracking this down and submitting reports to the package 
maintainers?
Yes, but the data_dir doesn't have to be inside the PEAR_INSTALL_DIR, 
though it's the default location. But you can set it to any directory.

Ok, it just seemed to be a cool gadget. I had the idea when I 
overwrote the tooltip function.
Oh yes, indeed. I had a lot of fun with that one :-/ It even seems 
that once a non-existent driver is loaded, all others are flushed. 
Very weird...
Er... Are you sure? I'm pretty confident I used PEAR's 
PEAR_INSTALL_DIR as path. Nevertheless I'm glab my patch made it into 
CVS ;)

Cleaned up and committed, thanks. I removed the links to Wikipedia 
because it seemed odd to link to a dictionary from a calendar, and I 
had too many false results.

There are still some issue, mostly limititations in Date_Holiday 
probably. It's too odd that you have to find out yourself if a 
translation exists and which one. This should be done inside the 
package. It's even broken at the moment because you are looking in a 
hardcoded PEAR path for the data files, but we should really look at 
PEAR's data_dir configuration variable.

Locales are not working properly either, I still have to look into 
that. But I want to get it commited, it lingered on my harddrive for 
too long.

I supposed that. But you know... You can never be sure ;)
I do not think there's going to be a lot of changes on my side. If at 
all. For me, it's working as intended. I'm just glad you like it :)

I already changed this in my local copy.
This is not necessary, PHP abstracts the directory separators from the 
underlying OS.



Since I've already tweaked your patch locally a bit, I suggest that 
you keep your patched version, update once I've committed my version, 
and then send a new patch with any remaining changes on your side.

Here's an updated patch. There's nothing critical. However, it still 
would be better with these changes:



- Prevent the user from selecting the "Composite" driver

Technically there is no harm in doing so. The Composite driver is used 
to add other holiday drivers so a set of drivers can be used. It is 
already loaded and it doesn't make much sense to add the composite 
driver to tha composite driver. So it's no longer available as an 
option to the user.



- Generate the file location of the translation files in a platform 
independent way

I've been using '/' all the time, now replaced with 
DIRECTORY_SEPARATOR (Date_Holidays needs the full path to where its 
translation files are kept). This might have prevented the translation 
of holidays on non-unixoid systems.



Sorry for the inconvenience. I should have thought of this before.

Finally, great work!

So, here's my idea of how this can be done. I wrote a new driver 
acting as an interface between Kronolith and the Date_Holidays 
package. The user is able to select a set of holiday drivers. 
Furthermore, the code attempts to translate holidays names whenever 
possible.



The entire thing can be switched of by the site admin. Thanks to Jan 
and Chuck for their help with the UI part.



Oh, and Kronolith is also getting its very own test.php with this patch.

Accepting, on the condition that Date_Holidays support should show up 
as additional calendar options to the user.

There is one more advantage: Date_Holidays lets you select several 
filters for holidays. So you can decide easily wether you only want 
national holidays or national holidays and holidays of a certain 
religion or only later one. IMHO this is a lot more comfortable than 
having to importing several iCal files manually. Plus it is very easy 
to remove holidays from the display once you decide you no longer need 
them.

I'm a big fan of Date_Holiday since it's first appearance and 
integrating it into Kronolith has been on my personal todo list since 
then.

It has many advantages over remote calendars:

- It isn't remote. You don't need to rely on the remote resource being 
available.

- It works for an unfinite future. Some recurring holidays can't be 
covered by iCalendar recurrence rules and need to be specified for 
every year; the remote file needs to be actively maintained.

- It is localized. You can have holidays in your local language for a 
foreign country.

- Probably more...

What benefit does this module provide over remote calendars?  Maybe we 
just need to make it easier to find generic remote calendars (like 
national holidays, etc) by linking to a repo from the Kronolith 
website or within the Kronolith application itself?

I still don't really like this idea, given that it's just a matter of 
adding a remote ical calendar. But I'm curious what others think...

I'd like to see support for the PEAR::Date_Holidays class to eliminate 
the need to add national and/or religious holidays by hand: 
<http://pear.php.net/package/Date_Holidays/>

I really hope this can be done...



I requested this already in ticket #2985. Since that proved to be the 
wrong place, I'm stating it here again :>