Bug with DATE_LOCALES

[Boris]

I think the '-' in some locales is wrong, it should be a '.' as it is in the other language-files. At my local PC it does not work with '-':

Code: Select all

$ cat test.php
<?
var_dump(setlocale(LC_TIME, 'en_US-UTF-8'));
var_dump(setlocale(LC_TIME, 'en_US.UTF-8'));

$ php test.php
bool(false)
string(11) "en_US.UTF-8"

Affected files:

Code: Select all

UTF-8/serendipity_lang_en.inc.php
UTF-8/serendipity_lang_hu.inc.php
UTF-8/serendipity_lang_is.inc.php
UTF-8/serendipity_lang_it.inc.php
UTF-8/serendipity_lang_pl.inc.php
UTF-8/serendipity_lang_pt.inc.php
UTF-8/serendipity_lang_pt_PT.inc.php
UTF-8/serendipity_lang_ta.inc.php
serendipity_lang_en.inc.php
serendipity_lang_hu.inc.php
serendipity_lang_is.inc.php
serendipity_lang_it.inc.php
serendipity_lang_pt.inc.php
serendipity_lang_pt_PT.inc.php
serendipity_lang_ta.inc.php

The tamilian language-file sets a englisch locale, but I think it should be "ta_IN.UTF-8" at least at the first place (en could be used as a fallback).

[garvinhicking]

Hi!

Good catch! Fixed & committed in SVN.

Regards,
Garvin

[Boris]

Only found it because I was playing with using DATE_LOCALES for setting LC_CTYPE in the lucene-plugin and nothing worked with en_US

[Boris]

Hi again,

this is not yet changed in the 1.2-branch. Is that on purpose?

[Boris]

As 1.2 shall go live on sunday I bump this question:

this is not yet changed in the 1.2-branch. Is that on purpose?

[garvinhicking]

Hi!

I'm a bit unsure whether to backport this, as I'm afraid that some systems might have properly worked with the old locale, so I only committed it to 1.3. The current locales were in for quite some time and haven't yet been reported as problematic, so I'd like to reduce the possible "Screwup" of the 1.2 release.

I'm not sure if I have the time to do solid testing if the changes affect anything...

Best regards,
Garvin

[Boris]

No problem. I just thought you might have forgotten it.

It's only the locales for displaying the dates, so it isn't a big bug IMHO.