No more two letter language codes. Use of 5 letter (minimum) codes (like zh_CN) everywhere.
- The locale keys should match the standard, that is 'ln-LO' instead of 'ln_LO' .
- I am not sure we should rename the locale folders however, because the _ notation is standard for locales on many linux distributions, and moreover required if people want to use gettext (which sucks with PHP, but... Well).
- I think we should add a 'messages' key, for example
$locales['de-DE']['messages'] = 'de_DE'
which would solve the problem above + allow different locales to share the same language file. For example 'en-UK' could share 'en_US' but with a different date format. (bad example because the is no en_UK .po file, but you get the idea).
- If we ever move $locales to the database, we should put admin for this into the 'Options' tab, with possibility to enable/disable some locales on a system.
- about auto detection: VERY IMPORTANT: blogs should be displayed with their own set locale. Moreover: POSTS will be displayed with their own locale (for the MORE text and date formatting) (FP doing this). Autodetected locale should only override blog and post settings if user has requested it in his profile.
- we need to update languages with locales in the datatbase (blogs and posts)
My vote for: _
Actually the spec says -
So - it is going to be…
Flags are named after the country code.
We have a problem when trying to represent locales with flags. Some countries may have different spoken languages (and different locales) but just one flag.
We may also add a ‘PHPcharset’ key to locales, in order to have a constant to use with functions like htmlentities (see example: http://www.php.net/manual/en/function.htmlentities.php)
Hi, I’m the new developer.. :)
Started the conversion to locale-only today, when I wanted to make the installation multilangual and asked FP a question about that. He said “don’t touch", because he planed to do the same.
So, I commited what I had done and will now stop with that.
Changing this, $locales should definitely go into DB, allowing to enable/disable them and setting the default one - from the Options.
Auto-detect by HTTP_ACCEPT_LANGUAGE is already implemented in the function locale_from_httpaccept(), don’t know if there is something to more locale-specific.
Using $locales[’xx-XX’] instead of ‘xx_XX’ is good, if it’s more standard. Adding the[’messages’] field is also useful, of course.
keep on hackin’ :o)
Note: locales should not be restricted to ‘xx-XX’. For example with chinese, the same locale could be encoded for Traditional and Simplified, with different charsets and messages. I don’t know how exactly this should appear in the locale name however. Some kind of extension, but which one (?)
> The locale used should (ideally) obey to this order:
> - current post (I’ll take care of this)
> - current blog (partially implemented)
> - user profile pref (not implemented)
> - browser pref (your impl)
> - options screen global pref (not implemented)
> - last resort: config file (en-US) since it’s not on the global
> options yet.