[Chandler-dev] EuroPython Localization wrap up and next steps

[Brian Kirsch]

On Jul 19, 2007, at 8:48 PM, Heikki Toivonen wrote:

> Philippe Bossut wrote:
>> Brian Kirsch wrote:
>> The most interesting thing though is the accelerator thing. As a
>> localizer myself, I have to say that it's impossible to make a choice
>> looking at the po. The contextual comment to disambiguate strings is
>> also a great idea.
>
> Brian wrote in the HTML page also that:
>
> "For example, the _("&New") string will not be able to retain the "&N"
> short cut if the translated string does not contain the character "N".
> In addition if there are specific shortcuts that are applicable to a
> locale there is no assurance that the character required will be in  
> the
> translated sentence.
>
> In parcels.osaf.views.main.menus there seems to be code that is doing
> close to the right thing. We need to model the rest of our strings  
> using
> this logic. In the example below, the portion that is not right is the
> "&P" in the localizable word "&Print...".
>
> MenuItem.template('PrintItem',
>           event = globalBlocks.Print,
>           title = _(u'&Print...'),
>           accel = _(u'Ctrl+P'),
> "
>
> I am not sure I understood what exactly is the issue and the proposed
> solution. First, some terminology:
>
> mnemonic: In the above example, the letter p is the mnemonic
> accelerator: Ctrl+P
>
> People sometimes say shortcut and mean either mnemonic or accelerator.
> It would be better to not use this term unless we can agree on what it
> means.
>
> Now, I don't think there are any problems with accelerators. AFAIK  
> they
> are typically left alone in a translation. So Ctrl+C is copy  
> accelerator
> in Finnish and other languages as well.

Yup, I am giving a +1 to accel. That seems to be the way we should do
all of our keyboard mappings separate from the localizable string. A
translation can not preserve a mapping if it does not have the
character in the string.


>
> Mnemonics will be different with each language. It seems to me like
> Brian is saying that if we have "&Print" in English, then "&Tulosta"
> won't work as Finnish translation because there is no letter P and it
> was not marked as mnemonic.

Yes, that is what I am saying.

> I could not figure out what his proposed
> solution to this was.

My solution is not to include the Shortcut (mnemonic) in the  
translated string
but to instead find another way of assigning Ctrl+P in this case. I  
used the example:

> MenuItem.template('PrintItem',
>           event = globalBlocks.Print,
>           title = _(u'&Print...'),
>           accel = _(u'Ctrl+P'),


since it seemed to demonstrate the assignment of a "shortcut" outside of
the translatable string. I don't have a clear decision on what the  
best way
is at the moment. I need to do more research on Wx and "shortcuts".
But I do know the way we are currently doing it is not localization  
friendly.



> I would certainly expect "&Tulosta" to work, and
> the mnemonic to be 't', though. Anything else seems like a bug that  
> we'd
> need to fix. Localizers will almost certainly need to run the app  
> to see
> the context and choose appropriate mnemonics; it is no different  
> from us
> making the original mnemonics.
>

In the majority of cases the keyboard "shortcuts" will remain consistent
across localizations. ie. copy ("Ctrl+C") and paste ("Ctrl+P") will  
still be copy
and paste for most locales. This is why having the "shortcuts" in the
translated string is bad.


>>> So my proposal is to maintain a Localization Freeze for all  
>>> developers.
>>>
>>> Mimi will be the sole source of truth regarding what text should
>>> appear in
>>> our Chandler.pot. I will be the interface for converting those ideas
>>> in to
>>> strings in our Python code. I will also provide feedback to Mimi  
>>> when
>>> I see
>>> a string change that may cause localization problems.
>>>
>>> I will have commit rights to change any strings in the Chandler code
>>> that need to
>>> augment for better localization. For all commits, I will first  
>>> create
>>> a bug and attach
>>> a patch which will require approval by Philippe before I can  
>>> check in.
>>
>> I agree with the proposal. Again, I've been there as a localizer and,
>> indeed, without deep knowledge of the app, it's hard to translate.  
>> May
>> be though you could limit the number of commits: last batch of  
>> changes
>> Mimi made on Chandler.po amounted to 397 changed strings! (addressing
>> most of the issues you mention BTW).
>
> Maybe I misunderstood, because this does not make sense to me:
>
> So you are saying we will not change strings in Chandler code, but you
> will manually change Chandler.pot, which should be used by translators
> to create po files?

Nope. All changes would get placed back in to the Python code containing
the string keys. However, I would be the only one with commit rights,  
Mimi
would create the strings, and Philippe would be the reviewer.

This lets us maintain the Localization Freeze for developers while  
fixing
the issues directly instead of in an external .po.

>
>> To make things easier, I committed Mimi's current rework of the  
>> strings
>> in
>> svn+ssh://svn.osafoundation.org/svn/localizations/chandler/trunk/ 
>> en/Chandler-en.po
>> , using the svn structure and naming convention we discussed on  
>> IRC this
>> afternoon.
>
> I checked in the Swedish localization there as well, although I  
> realized
> that I should have asked first if this was ok. If not, please  
> remove it.
>
>
> Then to other issues mentioned here:
> http://people.osafoundation.org/bkirsch/postsprint/
>
> In general I believe that localizers will be people who will be
> reasonably familiar with Chandler and the concepts to be able to make
> good translations.

Well that is an assumption based on belief and not proven fact right?

I think it is a mistake to assume all our translators will also be  
Chandler
power users. In fact, I think it will be quite the opposite.

Either way, the easier we make the localization process the better for
all translators (power users or people new to the app).


> I am glad you got so many participants for the
> Chandler localization sprint, but I don't think you can draw much
> conclusions about the participants of that sprint and the difficulties
> they faced with Chandler concepts such as Item and Collection.

Why do you say that?

Here is a group of experience veteran developers who are multi-lingual
and had great feedback on the app. They are all familiar with intricate
computer concepts and have developed i18n / l10n apps.

This was a great example of what first impressions are when a
user hears about Chandler, downloads the app, and starts to
play around with it without first reading a bunch of manuals or
documentation.

I am going to have to disagree with your comments on this one.


> However,
> I think it would be a good idea to have a glossary of important  
> Chandler
> concept strings on the localization page with some  explanation and
> possibly some sample translations.

  +1. Why not use tool tips as means of also delivering these  
concepts to users.
For instance the tool tip on the calendar overlay says "Overlay  
collection". Well,
that is not really helpful for the majority of people. What does  
Overlay collection mean
to the average user. Instead if it said something like "Clicking this  
button allows
the user to view the selected collections together in a single  
Calendar view".

Of course that text is not the best either but you get the idea.


>
> You mentioned that we should use wx stock strings when possible, and I
> agree. However, I found some cases where this did not work, or worked
> only on some platforms, or worked intermittently.
>
Can you give an example. My examples were for OK and Cancel stocks
strings that do work on all platforms.

> You mentioned some concepts that should not be translated, but I
> somewhat disagree. There are brand strings like "Chandler" and "Open
> Source Applications Foundation" that usually would not be translated,
> but might in certain instances, like if somebody makes a heavily
> modified derivation of Chandler (Mozilla differentiates between
> rebranding and localization, for example). I am not sure about IMAP  
> and
> POP, although I wouldn't be surprised if these were actually  
> translated
> in some languages.


> I also wouldn't be surprised if the percent symbol
> weren't translated in some language.

I think it is safe to say that the percent is fine unlocalized.

> I definitely think "Dashboard" and
> "Triage" need to be translated.
>

I disagree and so would the entire localization Sprint team.

What is a Dashboard? is it the thing on your car or a feature on OS X?

What is Triage? Go look it up on wiki:

"Two basic types exist: simple triage and advanced triage

Simple triage is used at the scene of a mass casualty incident to  
select patients into those who need immediate transport to the  
hospital in order to save their lives and those who can wait for help  
later. This skill is required by first responders performing field  
triage on the battlefield or at a disaster site to assess the  
patients' need for transport prior to transportation becoming  
available. The categorization of patients based on their severity of  
injury can be aided with the use of printed triage tags or colored  
flagging"


Dashboard and Triage are overloaded words used in a specific context  
in Chandler.
In other languages first there may not be a corresponding word that  
correctly describes
the intent of these features, second there may be a number of words  
none of which correctly
describe the intent of these features, third the translator may end  
up choosing the wrong
word and thus conveying a completely different meaning to the features.

"Dashboard" and "Triage" are fixed concepts just as "Chandler" and  
"Chandler Hub" and
should not be localized.


> You mention the need to be consistent with capitalization, but I must
> point out that capitalization depends on context. Still, I am sure  
> there
> are some instances where we can be more consistent.
>

Please give some examples. Mine were different capitalizations for
the same feature set "Chandler Hub Sharing" vs "WebDAV sharing".

Please read through our Chandler.pot file (5666 lines)  there is a  
tremendous amount
of redundancy and miss use of capitalization and just general bad  
English grammar.

We need to clean this up and produce the best pot possible for  
translators to
work with.



> You mention that it is a problem when the same word/sentence has
> different mnemonic. I would be somewhat surprised if we could provide
> just a single shortcut for each string.

Why not?

Why are we overloading the term "New" for example with two separate  
keyboard
"shortcuts" that do different things. Is that good interface design?

I am sure there are valid cases where there needs to be different  
mnemonic
but these will be the minority.


> Sure, it has been the goal, and
> I did a fair bit of work to make it so. But to get 100% will not  
> happen
> without heavy refactoring in my opinion, and would run the risk of
> placing things in awkward contexts just so that we could maintain
> consistent mnemonics.

Please explain more about the phrase "awkward context". I do not
see how having consistent mnemonics across the app will be "awkward".

-Brian


>
> -- 
>   Heikki Toivonen
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev