Localization of WordPress

Labris,
The community I’m sure would welcome another localised version of WordPress. It will likely have to be something that you will have to do on your own at this time. Hopefully you have some friends who could help you. There is already a person co-ordinating German translation of the WP documentation. The WordPress Wiki is where that work is being looked after, among other things.
The developers will likely add their comments as well.
Thank you for offering your help!
Craig.

The problem is that there currently is no adequate “infrastructure” for easily supporting localizations. This is definetly something on the developer’s wishlist, but not scheduled yet (as far as I know). If you guys had any ideas on how to (efficiently) add localization support to WP, write down your thinking to this thread. Thanks.
Bye, Mike

Couldn’t you add some variables that are embedded in the HTML templates and are looked up in a language file like wp_en.txt, wp_ger.txt and wp_rus.txt?
Stephan

I only code enough to be able to keep my head above water if someone were to toss me in the ocean, but I think this could work…
Building on Stephan’s idea above, the development code for WordPress would use variables such as $post_button_text. Those willing to contribute, would create their lanugage file, based on these variables. Now for the original part of my idea, it seems to me that it would be a bit faster and more efficient if WP didn’t have to reference a txt file all the time. Therefore, a script would be needed for the developers to run and auto-magically generate a version of WordPress based off whichever language pack they specify, replacing the variables with the translated text.
In my head, this all makes complete sense and I hope I did a well enough job explaining what I’m thinking. Downloads of WP would be smaller and the operation of the program should be more efficient. No doubt, it will be quite a large undertaking regardless to replace everything in the WP code with the variables and would still be quite messy. If WordPress wants to be around for a long time to come though, it is something that will have to be done at some point.

I guess you’re right about the sluggishness that would result from the script looking up the right words in a textfile. But I also think that “building” your own version of WP would be a pain in the neck for many users (especially since this is one of the reasosns many don’t even consider MT as their loggin tool).
Couldn’t you somehow cache the language file on the client’s machine? Since I, just like wantmoore, know only very little about programming that this may all be totally off limits, but hey, sometimes you gotta think outside the box, right? ??

> There is already a person co-ordinating German translation of the WP documentation.
There’s only a person who started it and always said he’d be unable to spend much time on it since that person’s having his final exams in 3 months… ;o)
But we’re two Germans right now, so chances are we’ll end up having a translated FAQ next Xmas… :o)
Christian
P.S.: Localization has been asked for several times by now…
PP.SS.: wantmoore’s idea has one huge problem: You have to be able to look at the results while translating. That’s because grammer differs for languages, and if you have a $text_beginning and a $text_anding, chances are you’ll have to change the sentence construction while translating, and in order to produce some correct translation, you’d have to check the output. And I’m sure the dev team is not very keen on rebuilding a translation several times prior release, just because of a typo or something… (did this make sense?)

The easiest way to translate is just to change words in php-files. But if I’ll translate all these words, I will not have English version anymore. In this case there should be some selector at least . How do you think?

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

Roland,
I’m working on something similar right now for the entire WP-backend… we should compare notes sometime…