Localization best practices?

Question

We are localizing a cross-platform C++-based client-side application. The first localization pass was done in a big rush for a big partner on a short deadline, and now it's time to refactor it.

We currently have an XML strings file per locale, with a common key and a localized value for each resource. However, sending our not-necessarily-technical localizers an xml file isn't ideal -- they don't know about encoding special characters, etc etc. I'd like to use an easy, well-known format like Excel/csv with the localizers (also nice because we have server-side localization as well, which could be in a different tab of the same file), and then code-gen the strings files from there. It seems that Excel doesn't like to output UTF-8 CSV files, which is annoying, and is preventing me from throwing together a few quick scripts to automate the Excel --> strings file conversion.

This problem has been solved hundreds of times. What workflows have people found best, especially for cases where the localizers will be external to the company? I'm looking for something easy for non-technical users and also easy for the development team to then use to generate the strings file in some simple format like XML.

Answer 1

1. Use OpenOffice instead of exel, it can dump into UTF-8 encoded CSV.

2. We have .xls file with common ids and we send it to translation company. Then .xls is dumped into CSV using OpenOffice. We have a tool that generates our include localization files based on CSV file.

Answer 2

This is an interesting topic. In the past i've handled outsourcing in a variety of ways

One time we just used simple text files in a prorietary format. We had a different file for each language. the format was like:

 #LOCALIZATION_ID
 English String

The localizers had no problem with that. Another thing I've used is a custom xls spreadsheet app. Basically the app posted its data via web services to a server. No need to have intermediate file formats such as csv. It is nice because all the strings are versioned and allow multiple outsources to work on the same strings file.

You should probably be able to write some vba that will take your excel spreadsheet and output a UTF-8 xml file that the outsourcer could email to you. A big button at the top of the sheet that says "SEND XML FILE". and it would send it to either a predefined email address, or post it to your server. Worst case they could just email you the file itself.

Answer 3

I would be wary of any format with an ambiguous character encoding. Consider using XLIFF (though check with your translation vendors to see what tools/processes they're familiar with).

• XML in localisation: A practical analysis

Answer 4

Qt has a great facility for localization. The first step is to use their string class QString.

Next, you simply wrap any string literals in the tr() macro. The great thing about this method is that you don't have to waste time maintaining constants or defines. Just type the string you want, where you want it.

Later, you use a Qt utility to search all of your code units for translatable strings and creates a .ts file. This file is xml so you don't have to worry about your data being trapped in some proprietary format.

Now that you have a .ts file, Qt provides a translation editor called linguist. This is a very nice program that presents the strings to a translator (person) and provides some simple tools for managing the whole process. The program looks for common mistakes (differing punctuation), tracks the state of each string such as whether it has been tranlated or not, and whether the source string has changed or has been deleted. The program will also show context information for each string which the developer can include in the tr() macro.

When the translation is finished, the .ts file is compiled into smaller binary that is distributed with the application and loaded at runtime. Translations can be switched on the fly.

There is more to it than I can explain fully here. It is really a great system that is worth investigating.