[Chandler-dev] Localizing English
bkirsch at osafoundation.org
Thu Apr 5 15:16:49 PDT 2007
Although I agree with you that there are major advantages to
providing a English translation
there is also one major disadvantage that makes it not worth doing in
my opinion; the
architectural design of the gettext format.
Unlike Java's ResourceBundle, gettext relies on pre-compiled machine
readable .mo files
for localizations. Gettext was designed from a developer prospective
letting them define English strings in code.
Moving to an English translation, would mean additional work for
developers and QA.
Let me give you an example. I want to add the string "New Mail
Message" to the UI.
With a English translation I would need to do the following:
1. Define a key in code i.e.. new_message = _("osaf.new.message")
2. Merge the new translation with the existing en.po file for Chandler
3. Rebuild the en.mo gettext readable file
4. Restart the app and confirm the string was correctly translated to
5. Check in the updated en.po and the Python code containing the new
Asking developers to do the 5 steps above instead of one line of
Python code i.e..
new_message = _(u"New Mail Message") is a bit much.
I have an additional concern that if for some reason Chandler was
unable to load
the en.mo file (permissions etc) the user would be left with an
Having said that, we are entering a period where development of new
code is being
superseded by documentation, testing, and localization.
So if we were going to move to an English translation strategy now
would be the
On Apr 3, 2007, at 12:05 PM, Philippe Bossut wrote:
> There's one bug (https://bugzilla.osafoundation.org/show_bug.cgi?
> id=8648) that made me thought about an old idea I had when
> localizing Chandler in French: what about creating a localization
> package for "English"? The strings in the code could then be
> considered as being in "geek speak" while the official end user
> facing English UI strings would be found in the localized English
> - It can be fairly difficult for someone like Mimi or others to
> hunt down strings in the code. Compare that to editing a po file
> which contains all the strings in one place.
> - It's error prone of course...
> - Such a change requires rebuilding the app (while a change in a
> localization package doesn't)
> - Sometimes it would be convenient for devs to differentiate 2
> strings in the code that just happen to be the same in English but
> could be different in another language (e.g. "from" in "from 8:00
> to 9:00" and "from John" are actually different and could be
> differentiated in the code if one could write "from (time)" and
> "from (person)" in the code, and let both be translated as "from"
> in the English po. Note that in this example the whole strings
> would be coded as "from %(starttime)s to %(endtime)s" and "from %
> (person)s" so the problem wouldn't happen but you get the idea...)
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev