[Chandler-dev] Localizing English

Brian Kirsch bkirsch at osafoundation.org
Thu Apr 5 18:00:02 PDT 2007


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




More information about the chandler-dev mailing list