On Apr 5, 2007, at 2:47 PM, Philippe Bossut wrote:
Hi Brian,
Brian Kirsch wrote:
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 agree that would be really annoying if that had to be done
systematically. Using for instance abstract made up messages as in
your example would bring us back to the sad days of resource
editing which is a step backward...
However, I think that when you introduce a new string, you don't
have to modify the po file immediately. The UI will display with
the string you defined in the code by default if no translation is
found. In 99% of the cases, that's fine.
So, the developers will never have to edit the po file. They'll be
perfectly happy running in "geek speak" (a fairly good
approximation of English...) and let the UI specialists fiddle with
the po for those stray strings really hard to word smith.
The only moment devs would have to edit the po is for those rare
cases where they want 2 separate messages while the English wording
is identical (the "from" example I gave).
So I'm advocating we change nothing in our coding habits and that
we additionally consider creating "en" resources so that Mimi and
PPD edit that instead of logging bugs when fiddling with strings.
This will also give us a solution for those rare
"homocryptic" (same writing - different meaning) cases.
Does this make more sense?
Ok, I think I might have misunderstood your original proposal.
So to sum up.
Keep English strings in Python but allow the creation of an en.po for
making changes during code freeze points. i.e. Mimi wants to refine the
language on a dialog without editing the code.
The keys (Unicode strings in Python) remain the same so as
not to disturb other localization .po files. Using a en.po would
allow us
to make subtle changes easily with out generating a rebuild of Chandler.
If I have correctly summarized your proposal then I would give a +1.
The most important thing is not changing the keys (English) that are
used by localizers to create .po translations. Your suggestion
accomplishes
this.
-Brian
Brian Kirsch
Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
B
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
