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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
