typical java i18n process - sending resource files to Translation companies to be translated

Question

There are loads of tutorials on using Java ResourceBundles to provide UI in multiple languages. However, there is a process question as regards typical interaction with translation companies that I can't seem to find an answer to.

Assuming for example that I don't know French, and need to employ a translation company to get translations for my app, would I send them

1. The default resource properties file "whatever_en_US.properties" including the key and English value, and get back "whatever_fr_FR.properties"?
2. "whatever_fr_FR.properties" with empty values and "whatever_en_US.properties" for reference?
3. some other combination?

Answer 1

Since your question is about a process and not about technology, I will try to give you thorough explanation. Assuming that you have application with no previous translation, the ideal process should look like:

1. Send English files for translation. Depending on your agreement with translation contractor you could use:

   • Your default properties files (you will be responsible for renaming them correctly)
   • Excell spreadsheet containing keys, English phrase and an empty column for translation
   • Gettext *.po file(s) if you are going to use gettext
   • Translation memory file(s) (i.e. Trados *.tmx files)

2. When you receive files back, you put these translations into product, create localized build and test it out. Surely, there will be some UI issues. Some of them you could fix on your own, some will require additional translation (like hardcoded strings), others will require shortening translation. Again, you will engage translation contractor and supply them with strings that need to be (re-)translated. You could use spreadsheet here (provided that there are not so many strings that need to be translated).

3. If you want to ship simultaneously (all languages at once), you need to engage translators early. Since UI strings will change (provided there is no hard-UI-freeze period or translation-freeze period), you will have to get your translations updated. In this case, you will need to supply already translated files with the strings that need to be translated (in English). If the changes are really small, you could send only the English strings and merge translations manually, otherwise it is best to use some kind of translation memory exchange format (gettext *.po's or trados *.tmx's are great here).

4. Translating files is usually not enough. Since usually there is no context given and different words may mean different things in a target language, translation errors occur. There is no way to know that they are in unless you know the language. That's why you need to take UI screenshots and send them out for review (it could be reviewed by your translation contractor, or somebody else depending on quality requirements).

5. Once reviewed, you will need to apply translation changes and test for UI issues...

That's about it, if we are talking about UI strings translation process. But please be advised that there is a lot of more to correctly localize an application (documentation, help files, icons, colors, sounds...).