WordPress › Support » Localization: Help Needed!

Otsukare
Member
Posted 4 years ago #

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.
Thanks!
jules
Member
Posted 4 years ago #

This is exactly what i needed! - Many, many thanks Otsukare!
Nao
Member
Posted 4 years ago #

Hi jules,
Are you interested in helping Otsukare translate? I am also a Japanese WP user and kind of helping him get this localization thing going. I think it would be great if you could share your translated language file with others!! (unless you are using the Japanese file Otsukare made).
Anonymous
Unregistered
Posted 4 years ago #

I love the idea, I would be glad to join for the French version.
Yuu
Member
Posted 4 years ago #

Sorry, forgot to log. So, I am joining !
TigerDE2
Member
Posted 4 years ago #

This looks really nice.
But what happens if wp is updated b/c let's say a bug was found?
Christian
matt
Troublemaker
Posted 4 years ago #

Well the localization code should be rolled into the main release sometime. (Soonish.)
Anonymous
Unregistered
Posted 4 years ago #

Please consider adding a Right-to-Left option to the localization code for Hebrew & Arabic users.
Yuu
Member
Posted 4 years ago #

Thanks allusion, I was hoping such words from you.
Any other thing I would like to see is a status page with all the on going translations, in order someone doesn't translate from scratch if someone else's already working on a given language.
Jason
Member
Posted 4 years ago #

I already started on a German localization, so I'll just roll it into this project. :)
Anonymous
Unregistered
Posted 4 years ago #

Why don't you use the wiki on wordpress.org to translate this file? It might prevent parallel (and repetitive) work.
Otsukare
Member
Posted 4 years ago #

Thanks everyone for your comments!
Yuu:
I really appreciate your help.
Could you cut & paste the translated file here whenever you are finished?
I will include it as lang_fr.php file into my language folder.
TigerDE2:
As to bugs...
I only modified parts that have to do with displaying language (i.e. message/menu/etc...). That is, all I (or whoever fixing the bug) have do is to check the relevant code in the original file.
I can say there's a 99% chance that you only have to do what you usually would on the original release version.
allusion:
I really hope you consider incorporating this into future development/release version after we get a few more language files lined up. For people like me who use multi-byte language, it's quite a work to solve single/multi-byte compatibility issues whenever new version is released...
Anonymous:
If you simply write Right-to-Left text on the language file, it should be displayed as is. You might also be able to do the same by adding the following class in wp-layout.css.
p .RightToLeft{ direction: rtl;}
Let me know if you could help translating too!
Nao
Member
Posted 4 years ago #

Hi,
I think Otsukare and other people involved are sleeping at this moment (It's past midnight in Japan, I am in the US), but he will be posing a reply soon.
Good point, Yuu! And Anonymous, It's certainly a good idea to use wiki. Soon we can get it started, so it will be more efficient not to start translating just yet. Thanks all.
Otsukare
Member
Posted 4 years ago #

Yuu:
I really appreciate your help.
I would definitely include it!
Jason:
Thanks for your help too!
We can work together to make it a great project. Hurrah for Deutsh!
(BANZAI)
Anonymous:
I agree with your comment on the use of Wiki. I want to use whatever everyone is the easiest to work with.
Could someone give it a good project name?
Jason
Member
Posted 4 years ago #

Otsukare: Looking at the files, it seems there are a few things you are skipping/not translating. Is there a reason for this, or have you just missed some things?
TigerDE2
Member
Posted 4 years ago #

Guess we'll have to start translating the readme then...
BTW: The German FAQ is near compleation (90%).
Somebody should revise it... (because I love making all sorts of mistakes... ;o) )
Christian
P.S.: @Jason: I think the Wiki idea is a good one...
Would you mind starting a page lang_de or something? (If you haven't already...)
Jason
Member
Posted 4 years ago #

New wiki pages: lang_de and WordPressLocalization
Yuu
Member
Posted 4 years ago #

No problem, am working on the French translation. I will post it as soon as I will be satisfied with it.
Otsukare
Member
Posted 4 years ago #

Jason:
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
http://wiki.wordpress.org/index.php/WordPressLocalization
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!
gugus
Member
Posted 4 years ago #

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:
http://www.loc.gov/standards/iso639-2/englangn.html
For RFC 3066, see:
http://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.
Otsukare
Member
Posted 4 years ago #

Hi gugus,
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?
gugus
Member
Posted 4 years ago #

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
Jason
Member
Posted 4 years ago #

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.
gugus
Member
Posted 4 years ago #

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
Jason
Member
Posted 4 years ago #

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.
Anonymous
Unregistered
Posted 4 years ago #

I started to edit the lang_de page. I hope this is not bothering anyone...
gugus
Member
Posted 4 years ago #

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
gugus
Member
Posted 4 years ago #

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
Anonymous
Unregistered
Posted 4 years ago #

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.
Anonymous
Unregistered
Posted 4 years ago #

Stephan: Thanks for adding your name in the copyright section... I added it in the top section, too.

1 2 3 4 Next »

Topic Closed

This topic has been closed to new replies.

WordPress.org

Forums

Localization: Help Needed! (102 posts)

Topic Closed

About this Topic

Tags

Code is Poetry