One thing though. If the current magentocommerce.com tools are used (such as the wiki), they need to be converted to utf-8 before any work can really begin. Localization needs utf-8 all the way.
the localisation has already begun. german language seems to be the first. right now all the parts of the language “file” habe been distrubuted to volunteer translators and some are already finished. the first step seems to work fine, next step will be to upload the new language and then so some finetuning.
it is relly a lot of work, more than i expected.
the german capter is already quite strong, so there is a good distribution of work.
Hi!
I want to colaborated with you, I think that is an incredible proyect
I can tried to translate into spanish.
Now, I’m looking for building a e-commerce with that system and i’ll be ready when you want to start with that proyect.
I vote for gettext, if that’s an option, because of its essential features; translations can be marked as “fuzzy”, have comments, plural forms, and will automatically be linked to all its code references so translators can quickly look up where in the source code a translation is being used. It’s also extremely easy to use, both for coders and translators (with a tool such as poEdit).
I’d suggest taking a look at this Wordpress page to see how Wordpress deals with translations. I see they’re registered at Launchpad, which was mentioned earlier in this thread. It looks like a good tool for collaboration and it’s based on gettext (using .po and .mo files for import/export).
I would also like to point out the importance of having an active conversation within the translation teams. For example, the teams must agree on a terminology for commonly used terms, otherwise there’ll be inconsistency which can lead to confusion among customers/users and make the software seem less professional. Each translation would ideally be reviewed by at least 2 other translators. I see that in Launchpad translators can mark a translation as reviewed, and until one text has been reviewed it will be marked with “Someone should review this translation”.
I think that people should carefully consider their skills in both primary and secondary languages before they decide to join a translation team. Keep in mind that just because someone knows 2 languages it doesn’t make them a good translator, and there are more than enough bad translations to prove that. A poor translation isn’t always better than no translation at all, because a poor one may actually lower the credibility of a company.
evalder - these are good points and we considered them. For now (and this might change later) we are going with CSV files for the translations. We tried this out with the Polish and German community translators and it seems to be working. We are making some small adjustments and as soon as they are ready we will start translating the first design package of Magento to other languages.
My big issue with just having csv files is the following:
you are all looking to the german chapter - and yes they translated a lot! But if you look at the general english translation spreadsheet, it is alreay outdated, new fields and stuff being available in the newer files --> how do we ensure that we do not have to translate everything for each version?
I would hate to see that all work went down the drain with the next version, because order of fields and naming and other changes appeared uncontrolled.
With each release we are going to post/contact translations leaders with the changes and additions to the translations. Since the structure of the files match Magento’s modules there should not be any need to translate everything over again. If you have any questions about translations or to get the latest translation file updates you can PM <Michael> or me.
As i’m a bit lazy and i don’t like to do several times the same work, i wrote a shell script (for linux) to help in “upgrading” csv translation files.
As it can be useful to other translators, I share it. Please be careful and use it only if you know what you’re doing. And backup your files before using it.
So, basically, the script takes one by one csv files of a new version (let’s say 0.8.16100).
Then, for each line it checks if there is an exact match for the english US sentence in the already translated files. If there is one match, it puts it into a new csv file. If not, it puts the new version line (not translated).
You need to have 3 folders:
* new version of csv files: en_US/
* already translated csv files: fr_FR/ (for example)
* results of the script: result/
You can change the folder names in the script:
I recommend you make a copy of the en_US and fr_FR (or wathever) into a temporary directory. And copy the script in the same directory before running it. If every thing goes right, you can copy the result files to your magento translation directory.
I wrote this script mainly to upgrade from 0.7.14800 to 0.7.15480.
But i think this may be useful for future upgrades.
I just noticed that the csv files in app/locale/en_US/ folder didn’t upgrade from 0.7.15480 to 0.8.16100.
I figured this out by downloading the zip archive with full ver. 0.8.16100.
I made the upgrade by PEAR channel (and everything went right).
Is that a bug ?
Most common problem with translations are differences in grammar, use of language and the like in relation to context. Automated translations are crap for sure. Such automats can give hints and may be able to translate single words but, they always lack context. This can lead to wrong translations.
In Web environment one of most prominent examples for such a problem is “back”.
Is it “back to previous page” or “back to section” or “back to whatever”?
The other problem is grammar when there are variables within a string.
In English it might be correct to say ‘variable . “string“‘. In other languages there might be need to split string into parts:
‘“string_part1" . variable . “string_part2“‘
I like to recommend to establish some kind of glossary in english first.
In this relation “glossary” means to take one translatable string (word, sentence, whatever) and to describe it’s usage as well as kind of variable being used in combination. Afterwards the raw english language file can be changed to be translatable to multiple languages while taking grammar and usage of language into account.
I did enhance existing german translation for myself and stumbled over issues mentioned above. Some items let me look very stupid when I translate them from English to German. It’s anything but professional.
My experience in translating English to German goes from trivial applications up to programmer manuals and references (which are very hard to translate because “native language” of IT is English).
Edit:
Forum software goes crazy with &#xva;riable” (percent sign + word “variable” without space).
You should have a look at the atutor.ca translation system. It is quite effective and really collaborative orientented. Maybe such a system would be of great benefit for Magento.