Support » Requests and Feedback » Localization: Help Needed!

  • Hi, this is Otsukare from Japan.
    (Re-posted from:
    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!
    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.

Viewing 15 replies - 31 through 45 (of 101 total)
  • I am kind of jumpy about the split (word) – seen *nuke enough.
    Premilinary notes:
    There are three (3) types of changes:
    1) Change in the way strings are written (into the code. As done by Otsukare.)
    2) Changes (to the code) made by the localization team to achieve better operation in foreign lannguages.
    3) Changes (to the code) made by the developers to add features or improve functionality, etc.
    Smooth localization will be a long process. It might just happen that #3 gets far ahead if developed separately. It will be a real struggle to integrate the lines of development in case separate type #2 changes are numerous. You see, there would be changes going both ways. It could be a mess.
    NON-split development:
    The task will be easier if the task if executed in two (2) phases: A and B.
    A) First integrate type #1 changes into the code.
    Language is English. – This would yield a WordPress that does not offer any improved localization features. It would be plain vanilla WP 1.01 in English. In other words (English language) strings are in a lang file and not hardcoded into the code.
    Steps to achieve this:
    The current localized WP 1.0 code must be upgraded to reflect the changes in 1.01 (1.02?). I assume it contains type #1 changes ONLY. This would take a few days. During that time current development tree should be freezed.
    (I do not know about CVS much, excuse my ignorance.) The new localized WP 1.01 would be loaded into (a new?) CVS and then tested by the development team. If everything is OK it will become the new WP 1.1X. It will be in English only and functionally equivalent to the 1.01 / 1.02 (moment of freeze).
    B) Development will continue.
    The developers will continue to do what they want to do, type #3 changes. They would be in charge. Base language would be English.
    Localization team will do/ propose type #2 changes to the CVS (discussed somewhere).
    Translators will translate various language files (Wiki collaboration).
    This would lead to gradual development (evolution). There would be no integration crash looming in the horizon.
    I know this is a lot to ask. It would affect us all. It has to be agreed by everyone, starting with main developers. – I see this as an opportunity not to be missed. If the current proposed localized English version is OK it should be integrated before it falls too far behind. Early integration would save work in the long run.

    Ok, I can see where you’re coming from, jules, and you have some good points. I think what we need is for the developers to let us know what they want to do.

    As for the split…
    It is possible WordPress itself might split off if we create separate versions, so we cannot make a move on our own.
    I have uploaded the CVS on, but it probably is not easy to use for non-Japanese users.
    For now, it seems the best to create a repository named “Localization,” and store a CVS of new code on Sourceforge.NET.

    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.

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

    Nao told me about this localization, so I’ve started the lang_id and I’ll have some friends to help me.. 😀
    Anyway.. I’m not familiar with the wiki, am I doing a right thing there??

    Hi all!
    Quick update about localization. I talked with Matt last night, and he really likes the idea of localization, but he also sees the danger any sort of split could pose. For that reason, he’d like to get the groundwork for localization rolled out quickly, without a split
    After tossing around a few ideas, the ultimate decision has been to go with a custom function (wp_translate) so that future changes to translation can all be handled in one spot. wp_translate will work with localization files that will (unfortunately) differ a bit from those currently being worked on in the wiki.
    What does this mean? Well, the localization files in the wiki are good starts, and work can continue on them, but they will have to be converted to the new format at some point, so taking a break for a few days might be a good idea. Before conversion to the new format happens, though, I’m going to finish up the functions needed for translation and start swapping out the english from the current CVS versions of files. As soon as I have the beginnings of a new english localization file ready, I’ll make it available so translation can begin.

    Lucky I checked this thread before doing any more translations 😉
    Is the new format going to be similar to what we have now?

    Me too :-). I’d like to help with the spanish translation (es_ES, I’m from Spain), tell us where the new format is ready. (jlinares @ irc).

    Well, things have paused temporarily because there’s been a little bit of discussion… everyone just wants to be sure that this is done the right way the first time.

    The Traditional Chinese translation for users in Taiwan and Hong Kong is now available; you can download the file ‘lang_tw’ from the URL below:

    I just realized that the language file doesn’t contain text strings for index.php and for wp-includes/template-funcions.php. At least to me, these are the most important files to localize (together with comments.php), becase they have the text that the readers will see!

    Hi I’m Matteo and I’m new here. I wish to join the localisation project and write the italian version.
    Someone has an easy way to extract the string for a preliminary orthographic control?

    I think this is great, but I have one question though, How do we make use of the language files? By stating a “require” in the header of the index file? I would really like to know that. This is really great. I noticed that the spanish translation is going really slow, so I’m doing a spanish translation of my own, when I’m done with it I’ll hand it over to you guys. Greetings. 🙂

    Hi… i’d be interested to translate the French lang_fr file… nobody have done it yet ?! (quelqu’un a déjà traduit le fichier français ??) … i hope that Matt read this and implement this global effort work to the next 1.1 release…

Viewing 15 replies - 31 through 45 (of 101 total)
  • The topic ‘Localization: Help Needed!’ is closed to new replies.