On Jul 19, 2007, at 8:48 PM, Heikki Toivonen wrote:
Philippe Bossut wrote:
Brian Kirsch wrote:
The most interesting thing though is the accelerator thing. As a
localizer myself, I have to say that it's impossible to make a choice
looking at the po. The contextual comment to disambiguate strings is
also a great idea.
Brian wrote in the HTML page also that:
"For example, the _("&New") string will not be able to retain the "&N"
short cut if the translated string does not contain the character "N".
In addition if there are specific shortcuts that are applicable to a
locale there is no assurance that the character required will be in
the
translated sentence.
In parcels.osaf.views.main.menus there seems to be code that is doing
close to the right thing. We need to model the rest of our strings
using
this logic. In the example below, the portion that is not right is the
"&P" in the localizable word "&Print...".
MenuItem.template('PrintItem',
event = globalBlocks.Print,
title = _(u'&Print...'),
accel = _(u'Ctrl+P'),
"
I am not sure I understood what exactly is the issue and the proposed
solution. First, some terminology:
mnemonic: In the above example, the letter p is the mnemonic
accelerator: Ctrl+P
People sometimes say shortcut and mean either mnemonic or accelerator.
It would be better to not use this term unless we can agree on what it
means.
Now, I don't think there are any problems with accelerators. AFAIK
they
are typically left alone in a translation. So Ctrl+C is copy
accelerator
in Finnish and other languages as well.
Yup, I am giving a +1 to accel. That seems to be the way we should do
all of our keyboard mappings separate from the localizable string. A
translation can not preserve a mapping if it does not have the
character in the string.
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 could not figure out what his proposed
solution to this was.
My solution is not to include the Shortcut (mnemonic) in the
translated string
but to instead find another way of assigning Ctrl+P in this case. I
used the example:
MenuItem.template('PrintItem',
event = globalBlocks.Print,
title = _(u'&Print...'),
accel = _(u'Ctrl+P'),
since it seemed to demonstrate the assignment of a "shortcut" outside of
the translatable string. I don't have a clear decision on what the
best way
is at the moment. I need to do more research on Wx and "shortcuts".
But I do know the way we are currently doing it is not localization
friendly.
I would certainly expect "&Tulosta" to work, and
the mnemonic to be 't', though. Anything else seems like a bug that
we'd
need to fix. Localizers will almost certainly need to run the app
to see
the context and choose appropriate mnemonics; it is no different
from us
making the original mnemonics.
In the majority of cases the keyboard "shortcuts" will remain consistent
across localizations. ie. copy ("Ctrl+C") and paste ("Ctrl+P") will
still be copy
and paste for most locales. This is why having the "shortcuts" in the
translated string is bad.
So my proposal is to maintain a Localization Freeze for all
developers.
Mimi will be the sole source of truth regarding what text should
appear in
our Chandler.pot. I will be the interface for converting those ideas
in to
strings in our Python code. I will also provide feedback to Mimi
when
I see
a string change that may cause localization problems.
I will have commit rights to change any strings in the Chandler code
that need to
augment for better localization. For all commits, I will first
create
a bug and attach
a patch which will require approval by Philippe before I can
check in.
I agree with the proposal. Again, I've been there as a localizer and,
indeed, without deep knowledge of the app, it's hard to translate.
May
be though you could limit the number of commits: last batch of
changes
Mimi made on Chandler.po amounted to 397 changed strings! (addressing
most of the issues you mention BTW).
Maybe I misunderstood, because this does not make sense to me:
So you are saying we will not change strings in Chandler code, but you
will manually change Chandler.pot, which should be used by translators
to create po files?
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.
This lets us maintain the Localization Freeze for developers while
fixing
the issues directly instead of in an external .po.
To make things easier, I committed Mimi's current rework of the
strings
in
svn+ssh://svn.osafoundation.org/svn/localizations/chandler/trunk/
en/Chandler-en.po
, using the svn structure and naming convention we discussed on
IRC this
afternoon.
I checked in the Swedish localization there as well, although I
realized
that I should have asked first if this was ok. If not, please
remove it.
Then to other issues mentioned here:
http://people.osafoundation.org/bkirsch/postsprint/
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.
Either way, the easier we make the localization process the better for
all translators (power users or people new to the app).
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?
Here is a group of experience veteran developers who are multi-lingual
and had great feedback on the app. They are all familiar with intricate
computer concepts and have developed i18n / l10n apps.
This was a great example of what first impressions are when a
user hears about Chandler, downloads the app, and starts to
play around with it without first reading a bunch of manuals or
documentation.
I am going to have to disagree with your comments on this one.
However,
I think it would be a good idea to have a glossary of important
Chandler
concept strings on the localization page with some explanation and
possibly some sample translations.
+1. Why not use tool tips as means of also delivering these
concepts to users.
For instance the tool tip on the calendar overlay says "Overlay
collection". Well,
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".
Of course that text is not the best either but you get the idea.
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.
You mentioned some concepts that should not be translated, but I
somewhat disagree. There are brand strings like "Chandler" and "Open
Source Applications Foundation" that usually would not be translated,
but might in certain instances, like if somebody makes a heavily
modified derivation of Chandler (Mozilla differentiates between
rebranding and localization, for example). I am not sure about IMAP
and
POP, although I wouldn't be surprised if these were actually
translated
in some languages.
I also wouldn't be surprised if the percent symbol
weren't translated in some language.
I think it is safe to say that the percent is fine unlocalized.
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:
"Two basic types exist: simple triage and advanced triage
Simple triage is used at the scene of a mass casualty incident to
select patients into those who need immediate transport to the
hospital in order to save their lives and those who can wait for help
later. This skill is required by first responders performing field
triage on the battlefield or at a disaster site to assess the
patients' need for transport prior to transportation becoming
available. The categorization of patients based on their severity of
injury can be aided with the use of printed triage tags or colored
flagging"
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.
"Dashboard" and "Triage" are fixed concepts just as "Chandler" and
"Chandler Hub" and
should not be localized.
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".
Please read through our Chandler.pot file (5666 lines) there is a
tremendous amount
of redundancy and miss use of capitalization and just general bad
English grammar.
We need to clean this up and produce the best pot possible for
translators to
work with.
You mention that it is a problem when the same word/sentence has
different mnemonic. I would be somewhat surprised if we could provide
just a single shortcut for each string.
Why not?
Why are we overloading the term "New" for example with two separate
keyboard
"shortcuts" that do different things. Is that good interface design?
I am sure there are valid cases where there needs to be different
mnemonic
but these will be the minority.
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".
-Brian
--
Heikki Toivonen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
