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