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 Sourceforge.jp, 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.
Hello,
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:
http://rt.openfoundry.org/Foundry/Project/Download/Attachment/7744/5915/lang_tw.php
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…
