Hi Philippe,
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
to easily
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
English
5. Check in the updated en.po and the Python code containing the new
string "osaf.new.message"
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
unusable UI.
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
appropriate time.
-Brian
On Apr 3, 2007, at 12:05 PM, Philippe Bossut wrote:
Hi,
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
files.
Advantages:
- 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...)
Thoughts?
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
