[Chandler-dev] Localizing English

[Philippe Bossut]

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