dates are currently not localized / #3357

I localised calendars and as I remember (it was 2 weeks ago) it was not finished yet. In a free time (hehe) I finish it and commit changes.

It was not finished yet change made 2-3 weeks ago, so I don't remember ale the things. I have no time at lately, but I try to commit "my way" as is tomorrow.

I've committed the fix. The main differences are:

1. function setLang() in common.inc.php calls setlocale() to set the proper locale for date formatting.
2. the config settings FORMAT_DATE, FORMAT_TIME and and FORMAT_TIMESTAMP have been removed. Proper format strings will have to be provided by translators as regular language strings. So each user will see the dates properly formatted according to its preferred language.
3. a new config setting FORCE_LOCALE has been added: it can be used to override the per-user setting and force the same locale for all languages. The most important use for this setting is that setting value "C" completely disable localized formatting. Useful if the underlying PHP platform does not have proper locale support.

There is a minor issue with the setlocale() call: the names of locales vary among platforms. So, in order to be as portable as possible, I used the feature of setlocale() that allows to specify more than one locale name. Each name is checked in order, until a valid one is found. For example for en-US language, the string is "en_US.utf8,en_US,enu". The first one "en_US.utf8" is the name used by most unices with utf8 support. The second one "en_US" is the same without utf8. The third one "enu" is the name used by Windows-based servers. If you know of any other names for platform we want to support, they must be added to the string. This string needs also be localised in every language tables.

I just looked at your code and now understand, why using the translation table is not sufficient to translate Dates with Weekdays or Months.

Anyway, since the gmstrftime() function does not work as expected on my version (see attached screenshot. The %e parameter is ignored), I do not trust it at all. I understand that you want a perfect translation, but I am for stability first.

If we cannot fix the missing day number on my php version soon, I vote for reverting the setlocale() and gmstrftime() stuff. Sorry. Saying this is hard.

Please also read I do not like new features

Things like this really makes my day. It makes me hurt to see how crappy PHP is with stability. Although we could probably do not better, there still is the feeling I want to throw something on my office wall. I will build a PHP voodoo puppy which I can torture with needles and stuff.
I honestly thought not just twice how much effort it would be to fuck PHP and rebuild streber from scratch with rubyOnRails. But hey: I only got one life...

Live is a bitch and then you die :)

Sorry for being too restrictive. I don't want to look like a "boss"...

Using %d fixed the missing day problem. It took a while until I figured out, how to get a German date be localized. Since the %d does the fix, let us keep the current implementation.
If some users complain, we can easily revert the changes.

I don't think that implementing an own localized version of gm would be a good idea. Although it would be easy, it would further slow down rendering.

Could you add a small chapter on to be translated locale settings to the Translation Guide. I see that there are four important keys:

 en_US.utf8,en_US,enu|list of locales
 %b %d, %Y|strftime format string
 %I:%M%P|strftime format string
 %a %b %d, %Y %I:%M%P|strftime format string

or are there some more? Maybe some links to the php functions will help translators to figure out what is meant...

You are perfectly right. I am still working on a windows system :) If this is really a known problem, we could easily replace %e with %s if OS == Win . This would be a sufficient solution for the problem.

btw: Excellent work on the translation guide!

Really? I didn't know that. Good to know. I don't have access to a Windows-based server, so could you please help test that? Try changing the following lines:

from render/render_misc.inc.php, lines 585-587

        // fix %e formatter if not supported (e.g. on Windows)
        if(strftime("%e", mktime(12, 0, 0, 1, 1)) != '1')
            $userFormatDate = str_replace("%e", "%d", $userFormatDate);

into

from render/render_misc.inc.php, lines 585-587

        // fix %e formatter if not supported (e.g. on Windows)
        if(strftime("%e", mktime(12, 0, 0, 1, 1)) != '1')
            $userFormatDate = str_replace("%e", "%#d", $userFormatDate);

(third line changed) and let me know if it works. Thanks!

I work with a language encodede with UTF8, but all the date are wrong encoded

Damn... according to MSDN:

The set of available languages, country/region codes, and code pages includes all those supported by the Win32 NLS API except code pages that require more than two bytes per character, such as UTF-7 and UTF-8. If you provide a code page like UTF-7 or UTF-8, setlocale will fail, returning NULL.

So apparently gmstrftime() can't be used to produce correctly utf-8 encoded strings under Windows. We need to convert them explicitly with utf8_encode(). It's really a shame.

In my opinion we should revert to old functions - we are not prepared to do such a big revolution...

These are really minor problems, that can easily be fixed, IMHO. I just need a hand testing them under Windows...
Anyway, you don't need to actually revert all the code, if you don't want to include it in v0.08. Just make the default value of the configuration setting FORCE_LOCALE to "C" instead of "". People who are unaware of the feature will not even notice that it exists.

Well... let's not exaggerate... it's not a bomb! It's not out of control. It works under Linux. We know how to fix it under Windows. There's an easy way to skip the code entirely on all other platforms, in case it doesn't work. We can conceivably check the feature programmatically at install time so that the user is not even aware of a workaround. What more do you want? Frankly I don't understand what are you afraid of.
Anyway, as I replied to madlyr in Translation Guide, we can get away even without setlocale if we want to. The feature can easily be made optional, so performances will be unaffected unless the user wants. Maybe I should just stop talking and provide a working implementation. Maybe we could profile it and find that it doesn't affect performances so much...

to ganesh:
You are perfectly right. Discussing for the sake of discussing is of no good. There is always the force of "facts". If you implement a working solution, I am very happy to use it and concentrate to other problems.


to madlyr:
I like names a lot, because it makes a program less technical and more "human". Hard to explain. I think that even in the translations we not go for personal taste but for accurate meaning. In this putting the format into the translation is already a little bit weird.

Anyway. The best option for overwriting the display of names would be an option that could be placed to the customize.inc.php. We could easily overwrite translation keys there, although it needs some documentation.

I agree. Customization for date/time display SHOULD be in configuration.inc.php.

Not everything can go in configuration.inc.php. For example, strings like '%a %b %e, %Y' (or whatever equivalent we will use when we ditch strftime) have to be language dependent. The English "Fri Nov 27th, 2007" becomes in Italian "ven 27 nov 2007": the name of the month has moved in third position and there's no comma. If you put those strings in configuration.inc.php you are forcing the same format for all users regardless of their language settings. For an Italian user, reading "ven nov 27, 2007" is even more confusing than not translating the date at all.
What exactly are you suggesting to put in configuration.inc.php?

any progress on this?