Hi, this is Otsukare from Japan.
(Re-posted from: http://wordpress.org/support/6/1879)
For people like me who are using self-localized WP, there’s a lot to do whenever new version is released: modifying each file to fit the intended language and mail() function, etc.
To solve this, I made this multilingual edition hack. The advantages of this are:
1. Non-English user can easily modify WP’s language by just updating a language file (e.g. lang_ja.php).
I need your help in:
1. Please download & test it! http://wordpress.xwd.jp/files/
2. Reporting bugs, and/or fixing them if you can.
3. Translating language files (e.g. lang_de.php, lang_fr.php) into your language (only Japanese version is available for now). All language files other than lang_ja.php are dummies.
4. Give me feedback -good or bad.
No problem, am working on the French translation. I will post it as soon as I will be satisfied with it.
The current file does not include some easy expressions and explanation during installation.
Seems like many people are joining in here, so I hope the file fill be completed before too long.
There are people already translating the language file into German and French. At this point, we probably should add remaining phrases to the template (English file) after those initial translations are completed.
Thanks for starting the Wiki page!
From now on, let’s move this discussion to
The Wiki won’t diplay multi-byte (Japanese, etc.) text correctly, so I will have to post a link of that file on my server.
Also, please modify the copyright note at the top of each file to those who translated!
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:
For RFC 3066, see:
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.
If it is confusing to use country codes, let’s use ISO 639 or RFC 3066 as you mentioned. It will not be hard because all we have to do is to change file names.
We decided to use Wiki to reflect everyone’s opinion as it goes, so go ahead and make changes when you think it for better. More work will be affected if decision are made later, so e should change the names right now.
I hope we will be able to choose language, time zone, time format, etc. when you first access install.php or while you are running WordPress in the future. But I think completing language files is the first thing we have to work on, in order to smoothly turn this project over to the development team.
I am just proposing the basic organization. The program may require rebuilding (for example, as v2.0 RC). Or we can keep expanding v1.0 to achieve the goal.
I wonder how the development team will be working toward multilingualization?
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.
Seems to me there should be a split here: 1.0.1 (after list_cats is fixed) should be used for localization, while regular development continues. Once localization is finished, the localized version should be caught up to the regular version, and then further development continued on the localized version.
As for including time/date formatting and wp-config-extra.php’s day names and month names in the translation files, I’ve created a custom WP-time/date formatting function that would eliminate the need for wp-config-extra.php’s translations. Basically, the custom function would allow you to use the formatting styles for either date() or strftime(), the latter being preferable for localized versions because with setlocale() in the localization file it would mean automatic translation of day/month names. I’ve mentioned it to photomatt, so maybe “1.0.1 Localized” is the place to roll this out.
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. 🙂
gugus: The problem of setlocale could be avoided like this:
DO include wp-config-extra.php’s day names and month names in the translation files, ESPECIALLY (or only?) for languages that are less likely to be available for setlocale (such as Schwytzer Dytsch).
Then, make the use of setlocale an advanced option available in the backend, specified by the user, defaults to none. People who enable setlocale can use strftime, the rest still use date.
As for organizing a split, I think we’d have to talk to photomatt about that.
I started to edit the lang_de page. I hope this is not bothering anyone…
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.
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?
gugus: some of the ‘Du’/’Sie’ confusion could be my fault… I’m not sure how consistant I was in the first portion I posted… somebody will have to go through at some time for each language file for consistancy with that kind of thing, and things that should be translated the same way every time.
Stephan: Thanks for adding your name in the copyright section… I added it in the top section, too.
About the Du/Sie issues, I am just starting to work through this baby 😉
But I tried to stick closely to what was already there. I guess I can just go for “Du”. I guess now’d be a goo time to register on this board 😉
- The topic ‘Localization: Help Needed!’ is closed to new replies.