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?
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
