gugus

Internationalisation: 1) and 2) of Jules’ list.

If there is a split it should be a short as possible due to the reasons that Jules mentioned. Been in too many projects where a split enabled us to go forward with our development but the merging of the code later on proved to be a major pain in the arse, i.e. errorprone if not done properly – and on top of that, also errorprone if done properly. The less time and development there is between splitting off and merging, the easier.
If we can get the dev’s to agree on integrating the internationalisation directly into their main branch (or whatever the word in CVS is) that would be best for all and one does not have to worry about splitting off and merging again. I would root for English as first language to be supported as well. After that, localisation can be completely independent of the internationalisation part in the main code.

Stephan: Great! One thing I saw when having a quick look yesterday: if we could use either ‘Du’ or ‘Sie’ throughout the translation, that’ll be great. Flip a coin? Or offer two different language files?
Cheers, Roland

Jason, the configurability is exactly what I was thinking about when referring to V2. If it is already provided in the first localized version, great. One thought to discuss is if it makes sense to pre-configure a language, i.e. setting the setlocale option, in the language file. On top of that, we could make it user configurable.
Anyhow, to get rid of the Swiss-centric view, I would expect that the problem also will occur for e.g. Japanese, Arabic or Chinese pages that are hosted by US/Canadien providers (just an example). Or about every other “complex” language that necessitates a separate language pack installation on an OS. I have no clue if providers usually install these language packs or not.
Bottom-line: making it configurable should help. However, we still might want to include these names in the language files to support all set-ups.
Cheers, Roland

As for the split: Yep, I think splitting off 1.0.1 would be best. The question still is how do we organize this.
As for the day and month names and use of setlocale(). In general I do agree that on the one hand, it would be nice to use the names from the chosen locale and down the road, we could even use gettext or catalogues (if supported by php?) for the translations. But on the other hand I do have a problem with it:
If I am not mistaken, setlocale() should return an error in case the language code is unknown or a locale not installed. Do we want to tie the WP languages to the installed/supported languages of the OS? What if my web hoster’s box does not support my language? I just looked up setlocale() and I think that we would have to provide different locale names when running on windows; if I am not mistaken.
My background: I will have a problem with my blog if using setlocale. It is in Swiss-German. There certainly is no locale for Swiss-German. Now, if I could go into my provider’s box and install my Swiss-German locale to get my day names, etc, that’ll be nice – but I highly doubt that they allow this. Background: no de_CH is not Swiss-German, but how German is written in Switzerland. Swiss-German is only spoken. The closest you get is with gem-CH or something like x-sil-gsw.
However, if the date/time functions are split into separate php files, I can easily run my own version of it for my website. Or we’d denote the usage of locales for v2 of the internationalization effort. ??
Cheers, Roland

Hi Otsukare,
Ok great. You are certainly right about translation being of highest priority.
As for the development organization:
I was also wondering how we achieve this best. The more that 1.0.1 is out now and your changes are based on 1.0 afaik. We could and should fix up 1.0.1 instead but how do we know that there won’t be a 1.0.2 out by the time the localization is at a “sufficient quality” level?
On another note, how should we handle fixes/extensions to your localization? Are you keeping track of them and merge them into your codebase? Shall I send diffs to you if I have any extensions/fixes? Do we have another place to save them?
We have the language files on the Wiki, but we should also put the code files somewhere. I don’t really like the idea of putting them on the Wiki where everyone can change them. Too many hackers out there nowadays.
Cheers, Roland

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.

I actually just did translate parts of WP for my homepage into Swiss-German (hey, there are strange languages out there) and made the language configurable. I currently can switch between English and Swiss-German. I might do a German translation as well.
However, I’ve only translated part of the user interface that I need for the people reading my blog in Swiss-German, i.e. admin user interface is not translated, the comments handling is not translated, installation is not translated, etc.
The approach I took was to create a language file WPINC . “/lang/” . LANG “.php” including all the strings I needed for the limited translation into my language. The strings are define()d in there, so it should be fairly straight forward to translate it into other languages.
All I had to do then was to define a LANG var in wp-config.php and then include the correct language strings file in wp-settings.php. Note, the definition of LANG and inclusion of the language file would have to be fixed for a proper translation of WP. I.e. my stuff does not work (yet) so that it could be used for the installation, but it is a start. However, it supports everything I need right now.
Also the language could be automatically detected (or at least, what language is set in the browser through HTTP_ACCEPT_LANGUAGE), but I do prefer the configurable setting of the language in a file or DB (let’s me enforce a language for my private site).
My partial translation is based on WP1.0 and if there is interest, I can send diffs or whatever is needed to the developers with what I started to do. Unfortunately, I will not have time the next few days and I also will have to sort through my other changes I did before providing any patches. I hope to have time this weekend or at latest next weekend to sort it out though.
Some add-ons to the discussion here:
1) using separate language files is fairly straight forward to extend and translate. One file vs. multiple files: might make sense to split it up, depending on how big and manageable the files would be. Or it could be split up by functionality: installation, admin, (read only) user, etc, which enables step-wise translation.
2) having different files for each language shipped and installed is the easiest way. No headache with generating (replacing texts) at installation time or shipping different language version for WP as proposed earlier
3) Don’t use text files, use php files/code to include (ok, catalog files would be kind of standard, but I don’t know if PHP supports them). Simple vars are not good enough. I did use define()s because some texts are used as default parameters for functions
4) Translation should also include correct default configuration for time, date, etc. formats (easy to fix since most is already configurable)
5) One should sift through the code and check for localization problems. This could be things as fixing up the order of parameters for printf()s (easy to do), getting rid of any pictures that are language dependant or support different ones. There’s more topics, such as different charsets, etc
Cheers,
Roland