| | 76 | ---- |
| | 77 | |
| | 78 | '''Update 26-02-2008 by Heikki''' |
| | 79 | |
| | 80 | The original statement of the problem, in the mailing list referred to above, is this: |
| | 81 | |
| | 82 | The problem: |
| | 83 | With the expanding number of languages it becomes more problematic to |
| | 84 | keep all language files synchronized. It also is not trivial what |
| | 85 | strings have become obsolete, causing people to translate text that |
| | 86 | actually is not used anymore. |
| | 87 | |
| | 88 | So the problem is really about synchronization - not about the format of the i18n files. |
| | 89 | |
| | 90 | What is needed is a check that each localization string exists in each supported language file, no more and no less. |
| | 91 | |
| | 92 | To me it seems there are plenty editors available that help do this; for example copy your files into a spreadsheet editor, sort the keys alphabetically, and there you go. If you want some procedure to do a check automatically e.g. before making a release, it still seems simple enough to write a small checker ourselves? OK, I'm disregarding fancy ideas like "deprecating" translations. |
| | 93 | |
| | 94 | What in my view we ''don't'' need is a tool that allows putting style information, like <b>, in a translation system. But this is exactly what IBM presents as an advantage of XLIFF: ''Fortunately, the XLIFF standard includes attributes for specifying string position in a dialogue, font type and size used for the text, and many other details. A tool specifically designed for software localisation can be used to visually adjust the dialogue layout during translation.'' (from * [http://www.ibm.com/developerworks/xml/library/x-localis/ XML in localisation: A practical analysis]). |
| | 95 | |
| | 96 | Even though this addresses a real concern I would still advocate an approach where the user-interface, as in HTML and CSS, is as decoupled as possible from anything else, in this case the translation system. To begin with I don't think the GeoNetwork practice of generating HTML from XSLT is a very good thing, and things will only become more pasta if we put style information in a translation system that your front-end developer shouldn't know. |
| | 97 | |
| | 98 | In my experience the simple approach of Struts has always worked fine, even if it's lacking a synchronization check: all i18n strings are resolved through the default translation file, unless your Java Locale is set to something else, in which case the localized translation file (recognized by appending the ISO language code to the default file name) is used first to look up the translation. No <use> <of> <xml> <where> <this> <isn't> <necessary>, just plain old property file syntax. |
| | 99 | |
| | 100 | To address the original problem (synchronization / consistency checking) I think the easiest solution is to settle for one format, possibly the existing one, and either find or else write a little checker that could be made part of the build process to ensure nothing is lacking or superfluous in the supported languages. |
