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

[Brian Kirsch]

On Jul 25, 2007, at 8:44 AM, Heikki Toivonen wrote:

> Brian Kirsch wrote:
>> On Jul 19, 2007, at 8:48 PM, Heikki Toivonen wrote:
>>> 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 think there is some misunderstanding here. I just tried this with  
> the
> Swedish localization, and it works. Here's what I did: I unzipped the
> sv.egg, Changed translated string in the .po file (&Arkiv for &File
> menu) and installed it. Pressing Alt+A opens the Arkiv menu just fine,
> even though the English original &File does not even have letter A.
>

My point was that having the "shortcut" in the string forces the  
localizer to
have to use a letter in string for that "shortcut". What if &F was  
the standard way
to access the file menu item in a specific locale yet the letter "F"  
was not in the
translated word for "File"?

  By having the "shortcut" in the string we are limiting
localizers ability to provide the best user experience for that locale.


> To recap, if we have the English original:
>
> &Print...\tCtrl+P
>
> this can be translated to the following Finnish entry:
>
> &Tulosta...\tCtrl+P
>
> The global accelerator is still Ctrl+P (we can use the accel= syntax
> rather than putting everything in one string of course) and the  
> mnemonic
> is &P in English and &T in Finnish. By the way, mnemonics may not  
> exist
> on Mac (?), so this may be causing some confusion... On Linux and
> Windows mnemonics are typically activated with Alt+<the underlined
> letter in the UI>, except for submenus where just pressing the
> underlined letter is enough. So if you have:
>
>
> &File
>   &Print...
>
> Then pressing Alt+F opens the file menu, and pressing p will  
> execute the
> action bound to the &Print... menu entry.
>
>> 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.
>
> +1 on this plan, now I understand.
>
>>> 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.
>
> It is based on assumption, yes, and I didn't necessarily mean power
> users, just users. I have done a few translations, but only for  
> software
> that I actually use myself. In other projects where I have  
> participated
> the translators seem to be people who use the software, as opposed to
> just some people translating random things (although I am sure  
> there are
> people like that).
>
>>> 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?
>
> I was referring to the above.
>
>> 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".
>
> +1
>
>>> 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.
>
> I tried to use stock edit menu entries Cut, Copy and Paste.
>
>>> 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:
>
> These mean something in the English language, something that is  
> related
> to the original meaning of the word and the function in Chandler. I
> think localizers need to find reasonable equivalents in their  
> languages
> for these important terms. If they don't get translated, these things
> will stand up like a sore thumb in a localized Chandler, and make it
> harder for people who don't know English to use the application.  
> Let me
> put it this way: what would you think if your email application had a
> button that said "Get 汉语/漢語" instead of "Get Mail"?
>

That is really not a fair comparison.

Do we localize the word "Chandler" or "Open Source Application  
Foundation"?

What if the sentence was "Get Chandler" and not "Get Mail". What  
would be
the translation for "Chandler"? There is none.

There is no right or wrong way to do this but based on the feedback I  
got at
EuroPython, 100% of the localizers suggested that key overloaded terms
such as "Triage" and "Dashboard" not be localized.

We can continue the debate further in 0.7.1.




>> 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.
>
> That is a problem with all translation. It is not unique to  
> localization
> of software.
>
>>> 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".
>
> I was being generic, without referring to actual Chandler code. But
> there are expressions in the English language that you would  
> capitalize
> all words when in title, but they would all be lower case when in the
> middle of a sentence, for example.
>
>>> 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".
>
> Mnemonics are limited to the letters available in the menu entries,  
> and
> they are further limited in that the same mnemonic can not appear  
> twice
> in a submenu. So suppose you have a submenu with entries To, Cc, Bcc.
> You can have t or o be the mnemonic for To, only c the mnemonic for  
> Cc,
> which leaves only b available for Bcc, which gives you &To, &Cc, &Bcc.
> Now suppose in some other context you need to give a mnemonic to Bcc,
> but the mnenomonic b is already taken in that context although c is
> free. Do you now give c as the mnemonic for the second Bcc, or do you
> change the text in some awkward way to have more available letters, or
> do you split things into different/awkward submenus (contexts) to give
> you more letters to work with?
>

Yup that is why I am advocating not using mnemonics in strings if we  
can come up
with a better solution. Like I said I would need to do some Wx  
research but
I imagine there is a easy way to assign a "shortcut" to a widget in  
code that
does not have to correlate to the widget string label.

With the addition of translator comments in Python code (0.7.1) we could
provide context in the Chandler.pot as to which "shortcut" applies to
which action / msgid.

This also eliminates having three different definitions of the same  
string
in our Chandler.pot just because a different mnemonic is assigned for  
each.

Getting back to the three definitions (which is a real use case in  
our Chandler.pot),
what if the translated string only had two letters?The Swedish word  
for "New" is "Ny".
If you need three different mnemonics and you only have two letters  
then you have
reach a quagmire :)



-Brian


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