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

[Brian Kirsch]

On Jul 25, 2007, at 10:11 AM, Jeffrey Harris wrote:

> Hi Brian,
>
>> 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.
>
> I'm not following your argument.  It's a hard and fast rule on Windows
> and Linux that mnemonics MUST be a letter in the menu title.  When the
> menu title is localized, the mnemonic will generally change, or as a
> first cut no mnemonic could be used.
>

That may be true. I was merely pointing out a localization  
restriction by
doing that and hoping there might be another way of assigning the
"shortcut" outside of the localizable string. Like I said, I was  
planning
on doing some research to see if my suggestion was even possible.

If there is not then we have no choice but to use mnemonics.




>> 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.
>
> What would be the motivation for removing the option for these strings
> to be localized?  It's not like every string *has to be* localized.
>
> I suppose if the translator thinks triage and dashboard are meaningful
> in their language they could neglect to translate those strings, but
> triage and dashboard are just an English verb and an English noun, I'd
> imagine a complete localization would usually want to use a different
> word for both of these.
>

There is no right way or wrong way to do this. We certainly could
include the keys in the Chandler.pot and leave it up to the translators
discretion whether to localize the values or not.

But since we are overloading English terms that can have many  
different meanings we
need to make sure that there are excellent comments in the Chandler.pot
regarding what a "Dashboard" is in Chandler.

Also even in localized applications there are cases where English  
strings persist
because they capture a globally accepted term.

I don't see the harm in providing translators the option of  
localizing "Dashboard"
and "Triage" as long as there are good comments in place. This is  
something that
is missing currently in Chandler and lead to a lot of confusion at  
the Sprint.

If I was not there to give meaning verbally to our version of  
"Dashboard" and "Triage" the
localizations would have been literal to the dictionary definitions  
of "Dashboard" and
"Triage" and thus incorrect with in the context of Chandler.


>> 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.
>
> Mnemonics seem to me to be a separate issue from global accelerators
> (and whether we allow global accelerators to be localized).  It seems
> unavoidable that mnemonics have to be localized.
>

That would be unfortunate. I would at least like to do more  
investigation before
certifying the issue "unavoidable".


-Brian


>> 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 :)
>
> Mnemonics need only be unique within a given submenu, so if you've got
> several "Ny" submenus under different menus, they can all use the same
> mnemonic.
>


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