Currently Simutrans is translated with the help of SimuTranslator, a tool that Frank does a wonderful job in keeping as user/translator friendly as possible. But, there is imho a fundamental flaw in the principle used to translate Simutrans. All translated strings are translation of set keys, keys that does not need to impart any useful information (an example is LOCO_INFO). If the translation of a key is missing, the key itself is shown. If the information that the key needs to convey is changed, already translated strings keep on showing the old (now possibly outdated) information until a translator reviews the text and updates it. Furthermore, there is no indication given to the translator that such an update is needed.
Newly added strings clearly have a tendency to be useful even if not translated, but far from all have. There is a very real fear that changes to the translation system will cause loss of existing translations that might take a very long time to be re-established. Nevertheless, this is a problem that will not go away, and I believe that something needs to be done. Simutrans is a very international game, and I think it is very important that effort is put into keeping it so.
There is an alternative; gettext; it has been mentioned before here on the forum. Prissi has stated if the project had been started today, gettext could have been chosen to handle translations (see
http://forum.simutrans.com/index.php?topic=4838.msg47661#msg47661). This system which is used by a great many open source projects works on a different principle. Instead of using specific keys; one language is chosen (this is usually English) as the base language. The entire string in the base language is then used as the "key". If a language lacks a translation to this string, the base language string is used. If the base language string is changed, existing translations of it will be marked as "fuzzy", showing the translator that a review is needed. Until a translator has reviewed the string, the base language string is used (unless the devs choose to use fuzzy string in game as well - which I would not recommend).
Since gettext uses the entire string as key, identical strings in various places will be translated identically, unless specifically set to be translated differently. There are two ways to specify this; by namespacing (each pakset could f ex have a separate namespace) and by prefixing the string with an untranslated selected string sequence; this would only be necessary for those strings that in the base language are identical, but that conveys different meanings (think Game as in "play a game" and as in "hunt game"), both which are valid within the same namespace. Further more gettext supports basic plural handling, allowing translators to translate a given string into as many plural forms as needed in their language. Grammatical gender support is however not very good/non-existent.
There are translator tools for both linux and windows for gettext (f ex poedit -
http://www.poedit.net/) as well as online solutions (f ex launchpad -
https://launchpad.net/) which allows translators to easily get an overview of what needs to be done. Translations are then sent to or harvested by a dev that commit them to svn/git. Offline translators work with plain text files (suffix po) that are compiled into mo-files, with error checking as part of the compilation.
I believe that with some prudent perl scripting, existing *.tab-files could be reassembled to *.po-files, minimizing the loss of existing translations. However, these reassembled strings should probably be marked as fuzzy...
Sorry for being so long-winded... if you are still with me... then: This would of course require quite a substantial effort from the far too few coders we have, as well as an effort from the translators. So my point with this post is to start a discussion if this is a desired change as well as a search for coders possibly interested in implementing the gettext system for Simutrans.
