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.
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. I could not figure out what his proposed
solution to this was. 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.
>> 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?
> 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. 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. 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.
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.
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 definitely think "Dashboard" and
"Triage" need to be translated.
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.
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. 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.
--
Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
