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

[Brian Kirsch]

Hey Guys,
So this is the final comments I am going to have on this subject till  
post-Preview since this
is sucking up to much valuable bug fixing time on my part.

1. The use of mnemonics as it relates to localization is not ideal.  
However,
      mnemonics in strings are the "accepted" way. So I would like to  
do some research
      to see how other projects handle the issue in regards to l10n.

2. "Dashboard" and "Triage" can appear in the Chandler.pot as long
      as we provide the correct context (comments) to prevent incorrect
      literal localizations.

3. Branding and localization are separate feature sets. A French version
     of Chandler is a French version of Chandler. If we want to
     provide branding abilities in 0.7.1 we should isolate it from the
     localization module and provide an alternate means of changing
     "Chandler", "Open Source Applications Foundation", etc.



-Brian



On Jul 25, 2007, at 10:38 AM, Heikki Toivonen wrote:

> Brian Kirsch wrote:
>> On Jul 25, 2007, at 8:44 AM, Heikki Toivonen wrote:
>>> 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.
>
> No. The mnemonic MUST be part of the string. That is the way it is  
> done.
> You can't have Alt+F open the &Tiedosto menu for a Finnish language
> application. This has been the standard as long as I have been
> programming, so I am somewhat curious where the need to do something
> different comes from...
>
>>> 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.
>
> I don't see how that is not a fair comparison. When email was  
> invented,
> the developers had to decide on terminology. They decided to call  
> these
> bits "electronic mail". And people who translated that to different
> languages chose to translate the terms as well, not use them as is.
>
> It is the same thing with us. We have somewhat innovative concepts in
> Chandler and had to come up with descriptive terms for them. It makes
> perfect sense for localizers to come up with equivalent terms.
>
>> Do we localize the word "Chandler" or "Open Source Application  
>> Foundation"?
>
> These are names, and names are typically not translated. However,  
> like I
> explained in an earlier message, these are really part of branding,  
> and
> there are situations where rebranding makes sense. For some famous
> examples, you can think about Mozilla rebranded as Netscape, and  
> Firefox
> rebranded as Iceweasel (http://en.wikipedia.org/wiki/Iceweasel).
>
>> 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.
>
> I believe it would be a bad idea to do something unusual with  
> mnemonics.
> There is a long history of how they are used, and we should just  
> follow
> suit.
>
>> 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 :)
>
> That is the way it is with mnemonics.
>
> -- 
>   Heikki Toivonen
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design