michi bloggt!

Hab mich vor kurzem rechtfertigen müssen, wieso ich etwas 'step01', 'step02',.. genannt hab, und nicht bloss step1, step2. Und dann erst bemerkte ich, dass dies ausschließlich deshalb erfolgt ist, weil ich 'Courier New' in meinem Text-Editor als Schriftart verwende, und diese nicht zwischen der 1 und einem kleinen l unterscheidet:
step01listItem

Peinlich, peinlich. Deshalb höchste Zeit eine vernünftige Schriftart für den Text-Editor:
-> Andale Mono (andale32.exe)

[merci an klemens für den tipp]

Internationalization in
-> Django (a python web framework)
-> Ruby-On-Rails
-> Struts

Django and RoR have very similar solutions to internationalization. Both rely on the GNU gettext tool, which serves messages from the according localised .mo-files. While a developer write his code, all he has to do to enable the localization of the application is to use the gettext-method (resp their python or ruby-equivalent).

str = gettext("My name is %s")

resp. as a shortcut

str = _("My name is %s")

can be written. When the page is rendered, the application substitutes that string with the according translation. In addition to gettext the developer is provided with the following tools:
* A script/command to extract all messages from the source-files. This will create a .pot-file, that is plain-text, and can be updated with a text-editor. This is for example necessary when dynamically built strings are passed along to gettext(). That script has to be smart enough to detect such manual changes, so that these changes dont get lost, when the script is run again.
* A tool/gui (preferably poEdit) to translate these message-files, which will create single .po-files for each localization. poEdit also allows the translator to add comments to certain messages, and to store how certain/firm she is about the translation.
* And finally a script that converts the .po-files into binary .mo-files, that are optimized for fast access.

Struts follows a different approach, which is somewhat similar to how it is solved in twoday:
Each string has to be referenced by a unique identifier

<bean:message key="app.hello" />

through which the application will look up the localized string. Localizations then need to be defined in .properties-files. Note: The developer should make up 'self-speaking' message-ids, which will ease the work with such ids. One of these .properties-files will usually function as a fallback, which is used when that particular string has not been localized yet.

Now, the problem with the second approach should be apparent: In Django and Struts the work-flow of the developer is not interrupted by subsequent opening/scrolling/thinkingAboutSmartMessageKeys/editing of big properties-files while he is working on the code (resp. view). He just types along, and wraps each string within simple _(.)-calls. The translation task itself is furthermore made straight forward thanks to the availability of open-source translator-GUIs, that can be used by non-tech-savvy people.

mmh... On the other hand developers are often very insecure on the wording, and forcing them to define a default wording, that will be used as a future key-identifier is problematic as well. Or, did i miss the point? How do these tools keep updates to these default wordings, when the application has already been internationalized?