Hi guys,
Shall I just change the Wikipage if I have any comments? Sorry, never used Wiki before, but I have some feedback…
1) Please use ISO 639 language codes or combine the country with the language code for the filename as defined in RFC 3066. This better identifies the file – which is language based and not country based. I’d rather be able to use de, en_US, en_AU etc in order to define German, English for the States, English for Australia, etc. This gives us much more flexibiliy. One could also think about including the charset name in the filename.
For ISO 639, see:
https://www.loc.gov/standards/iso639-2/englangn.html
For RFC 3066, see:
https://www.faqs.org/rfcs/rfc3066.html
2) Some improvements:
a) Please include initial language settings in language file. The ones I can think of right away are time/date settings.
E.g. from install.php: make date_format’s ‘Y/n/j’, time_format’s ‘g:i a’, links_updated_date_format’s ‘d/m/Y h:i’ configurable per language
b) Please make wp-config-extra.php’s day names and month names configurable in language file as well.
c) include (require_once) the English language file after your preferred languages file. The assumption is that the English translation is complete and one would at least see the English text. Note, php will simply ignore another define() of the same global so your preferred language’s text will be shown if available.
d) complete localization ??
3) As mentioned in another thread, I also did some localization of wordpress. However, mine is not even close to Otsukare’s state, i.e. mine: bare minimum for showing posts only – supports dynamic switching of language at runtime though. I will therefore stop my efforts and switch to this localization implementation somewhen…
Something to consider for future localization efforts (lower priority than localizing wordpress):
Should wordpress also support dynamic switching of lanuages at runtime? This would enable us to associate categories with certain languages. However, WordPress’ design is currently limited and the DB would need some replanning.
Yes, Otsukare’s version could easily support this. Or to be more precise: could support this at least partially.
Why only partially? The problem is two-fold and caused by the DB part:
a) We’d need support of having different option (and option group) description texts for each language in DB.
The option’s descriptions are written into the DB at installation time and hence are “fixed”. Easiest is to move these texts into the language file. The other solution is to add different language texts also in the DB.
b) We’d need support of being able to set different values for some options/data for each language in DB.
An example for an option: Timestamp is a classic example, that would certainly be different for every language. Ergo, some options would have to be in the DB for every language. Another example is blogname could be different for every language.
This is the tricky one and would need some rethinking on how to support option values for multiple languages in the DB.
Note, the easy work-around is to have different language’s blogs in different WP installations. Each WP installation has to have a different table_prefix though.
Jason: Coming back to the other thread from last week: my email is roli (at) gugus (dot) com in case you want to discuss anything further from that thread. Or we can keep discussion on the Wiki page or in one of these threads.
