Pippy has translation issues

[manuq]

The buttons "Run", "Stop Running" and "Clear" don't present the translation in the UI, at least for Spanish language.

[cjl]

This is because the tooltips are not flagged for i18n by gettext and so not in POT.

 http://git.sugarlabs.org/pippy/mainline/blobs/master/pippy_app.py#line141

gobutton.set_tooltip("Run")

 http://git.sugarlabs.org/pippy/mainline/blobs/master/pippy_app.py#line158

stopbutton.set_tooltip("Stop Running")

 http://git.sugarlabs.org/pippy/mainline/blobs/master/pippy_app.py#line173

clearbutton.set_tooltip("Clear")

[cjl]

I suggest using

"_Run!"
"_Stop"
"_Clear"

as these strings are already present as the Toolbutton labels and re-using them for the tooltips would require no additional L10n, just regenerating of the POT (let Pootle take care of this please) and and then an "Update from Templates" via Pootle and a re-commit of the PO.

Flag the tooltip labels this way today and you can have the commits tomorrow.

[cjl]

Minor tweak please (to exactly match the strings).

Change:

gobutton.set_tooltip(_("Run!"))
to
gobutton.set_tooltip(_("_Run!"))

stopbutton.set_tooltip(_("Stop"))
to
stopbutton.set_tooltip(_("_Stop"))

clearbutton.set_tooltip(_("Clear"))
to
clearbutton.set_tooltip(_("_Clear"))

Sorry if my earlier suggestion was not completely clear.

[cjl]

I have done a lot of the refreshes and commits, but I still have more before you should re-build. I'll post here when done (after some sleep).

[cjl]

ok, Pippy "Update from Templates" and Pootle commits are done, please generate new release and test.

[RafaelOrtiz]

Please test with V48.

[manuq]

Are the underscores in the tooltips intentional?

[manuq]

Image that shows the underscores in the tooltips.

[manuq]

Sorry now I see comment:2, thanks.

[walter]

Manuq was correct the first time. These attempts at i18n are not correct. The stings should be of the form:

_('Run!'), not ('_Run!') as is currently the case. Was this code tested? I cannot imagine how the i18n would have worked.

[RafaelOrtiz]

Yes it worked and was tested. the underscores follow the original strings and seem natural as they refer to keyboard shortcuts.

[walter]

I see that i18n works, but I still don't understand the purpose of the _. Were these always there? Is there any other place in the Sugar interface where we add _??? See attached screendumps.

[cjl]

To the best of my knowledge the toolbar strings have existed in this form (with the underscores) for some time. I believe the underscores serve as markers for keyboard shortcuts in this case (aka accelerators).

The logic behind re-using the toolbar strings in the tooltips was entirely driven by a desire to provide an immediate release for the 12.x OLPC build series with localized text in the tooltips. This meant using a pre-existing (already localized) string and the Toolbar strings were what was available and relevant.

Making this change to the tooltip strings, updating the POT in Pootle, then updating the PO files from templates in Pootle caused the already localized toolbar strings to be re-used for the tooltips, subsequent re-commits of all of the PO files made them available for the Pippy-48 build.

The basic assumption is that the presence of an extraneous underscore (in the context of a localized word) will be less disruptive in the tooltip than an entirely non-localized string.

Now that Pippy-48 has been built and released (hopefully to be included in the 12.x OLPC build), I would not be opposed to the idea of rethinking the toolbar and tooltip strings entirely for a future release and allowing adequate time for localizers to catch up with the changes in due course.

I hope that addresses your questions.

[cjl]

My recommendation for the ultimately necessary long-term re-working of the i18n of the toolbar and tooltip strings for Pippy would include eliminating the accelerators (keyboard shortcuts) entirely.

I also happen to think that the Sugar HIG should specifically recommend against using accelerators for two reasons.

1) Accelerators are special characters (usually underscore "_" or ampersand "&" prepended to (or embedded in) words that theoretically allow the following character to be used as a keyboard shortcut (usually when combined with the 'Alt" key). IMHO, no Sugar activity should have a pull-down menu so complex that keyboard shortcuts are needed to make it usable.

2) The simple fact is that localizers generally do not get L10n of accelerators correct in the vast majority of cases. I have formed this opinion in part by looking extensively at AbiWord L10n across many languages because AbiWord relies heavily on the "&" accelerator.

Pippy is a shining example of poor i18n and improper use of the accelerator as a keyboard shortcut, in that the accelerator-loaded strings are not continuous with a "hint" string describing how to use the accelerator. This violates the i18n principle of making all relevant information appear within a single string. Even in *Spanish* (the most common second language of Sugar users and developers) the Pippy toolbar accelerators have been improperly localized.

Allow me to point out the specific problem by pasting the relevant section of the Pippy PO file:

#: pippy_app.py:138 pippy_app.py:141
msgid "_Run!"
msgstr "¡_Empieza!"

#: pippy_app.py:139
msgid "<alt>r"
msgstr "<alt>r"

The above should be localized as <alt>e to match _E in "¡_Empieza!". But how is a localizer supposed to know that from the PO file?

#: pippy_app.py:152 pippy_app.py:158
msgid "_Stop"
msgstr "_Parar"

#: pippy_app.py:153
msgid "<alt>s"
msgstr "<alt>s"

The above should be localized as <alt>p to match _P in "_Parar". But how is a localizer supposed to know that from the PO file?

#: pippy_app.py:167 pippy_app.py:173
msgid "_Clear"
msgstr "_Limpiar"

#: pippy_app.py:168
msgid "<alt>c"
msgstr "<alt>c"

The above should be localized as <alt>l to match _L in "_Limpiar". But how is a localizer supposed to know that from the PO file?

When many accelerators are used in a given pull-down menu, it is practically impossible to avoid accelerator collisions (hypothetical example: _Edit and _Delete become _Editar and _Eliminar). One particular upstream project has reached the point where there are nearly as many accelerators in a single pulldown menu as there are letters in the Latin alphabet, let alone other alphabets).

Furthermore, although I cannot point to a specific example, I have lingering reservations about whether using "Alt" character combinations would ever be advisable on an XO laptop keyboard given the density of the key mappings the large number of potential keyboards/scripts we would like to be able to support. I have unconfirmed concerns about the possibility of this resulting in unexpected consequences depending on the keyboard layout and mapping. I think it could take a lot of exploration, that I am not personally prepared to do, to confirm or deny the possibility that this could result in unexpected behavior on some hypothetical (or future) keyboard layout/mapping configuration.

Just my dos centavos, YMMV.

[cjl]

I think this is why Walter's screen shot shows

_Empieza! Alt + R

I would also expect to see (but have not conformed):

_Parar Alt + S

and

_Limpiar Alt + C

[sascha_silbe]

Replying to cjl:

My recommendation for the ultimately necessary long-term re-working of the i18n of the toolbar and tooltip strings for Pippy would include eliminating the accelerators (keyboard shortcuts) entirely.

I also happen to think that the Sugar HIG should specifically recommend against using accelerators for two reasons.

1) Accelerators are special characters (usually underscore "_" or ampersand "&" prepended to (or embedded in) words that theoretically allow the following character to be used as a keyboard shortcut (usually when combined with the 'Alt" key). IMHO, no Sugar activity should have a pull-down menu so complex that keyboard shortcuts are needed to make it usable.

You're mixing up several different terms and concepts here and as a result of that arrive at a rather sweeping notion (removing keyboard shortcuts altogether, even from the HIG). I hope I don't need to point out that forcing the user to use a pointing device rather than offering to access the same functionality using the keyboard would result in a rather bad user experience for anyone except novices.

What you actually seem to be concerned about is the use of  mnemonics in labels. I agree that those can be hard to translate since you need to consider the entirety of labels visible on screen at any given time, rather than being able to translate them individually. For any given activity, it may even be impossible to translate them in a way that retains all accelerators, as only the characters of each label can be used and no two labels that are visible at the same time may have the same mnemonic.

[...]

Pippy is a shining example of poor i18n and improper use of the accelerator as a keyboard shortcut, in that the accelerator-loaded strings are not continuous with a "hint" string describing how to use the accelerator. This violates the i18n principle of making all relevant information appear within a single string. Even in *Spanish* (the most common second language of Sugar users and developers) the Pippy toolbar accelerators have been improperly localized.

Yes, Pippy is an example of how not to do it. From the source:

        gobutton = ToolButton(label=_("_Run!"))
        gobutton.props.accelerator = _('<alt>r')

It's setting both a  mnemonic and an  accelerator. That's wrong even without considering i18n. On top of that, it's translating both values. I'm not sure whether the accelerator should be translated at all (do we want different keyboard shortcuts to be used in different languages?), but at the very least there's the problem of consistency.

The solution is easy: Drop the mnemonic from the label. The accelerator alone achieves the purpose of providing a keyboard shortcut for the Run action. When setting the accelerator, Sugar will automatically cause a tooltip to be shown that contains the key combination to use; no additional hints required.

In addition the accelerator probably shouldn't be translated. It's the actual key combination that the user can use to access the function, not the string in the UI informing the user about the key combination. It needs to follow a  specific syntax; translating it naively would break its functionality (and possibly even the entire Activity). GTK already takes care of translating the keyboard combination when showing it on screen so it matches the labels on the keyboard.

It would be a good idea to allow individual users to customise the keyboard shortcuts, but that's a problem unrelated to translation. Language-specific keyboard shortcuts (accelerators) OTOH are likely to create much more confusion than they would be worth (by having the keyboard shortcut match the names of the actions in some more or less obvious way).

[walter]

And, of course, if you do want to disambiguate the keyboard shortcut for the translator, a #TRANS note in the code can be used.

[manuq]

Replying to sascha_silbe:

The solution is easy: Drop the mnemonic from the label.

+1

Also, can the underscores be removed from the PO files, so no translators effort is needed? Maybe automate this task with a script?

cjl, your effort to have a quick fix ready for the build is appreciated, but I think we have to fix it for real, so I'm not asking v48 for inclussion in the olpc builds.

[cjl]

Replying to sascha_silbe:

Replying to cjl:
You're mixing up several different terms and concepts here and as a result of that arrive at a rather sweeping notion (removing keyboard shortcuts altogether, even from the HIG). I hope I don't need to point out that forcing the user to use a pointing device rather than offering to access the same functionality using the keyboard would result in a rather bad user experience for anyone except novices.

Based on the links you provided, I would agree that I've used the term accelerator when referring to mnemonics. My concern is primarily with human-placed mnemonics that end up in PO files. My understanding from the Gnome i18n list is that the automatically added accelerators are a relatively recent development, but I could be wrong about that. I do not have nearly as strong a set of objections to those, but I do have lingering concerns about the path forward.

Perhaps the cause for my confusion is that I've primarily learned about accelerators from the localizer's perspective

e.g.
 http://translate.sourceforge.net/wiki/guide/translation/accelerators

where the term is often used synonymously with mnemonic, but perhaps this is an "old-school" usage.

I would not make a blanket proscription against all keyboard shortcuts, only those that are subject to the inherently error prone human L10n process via PO files (where little context is available to make good choices). In your words, mnemonics.

Yes, Pippy is an example of how not to do it.

I'm not sure whether the accelerator should be translated at all (do we want different keyboard shortcuts to be used in different languages?), but at the very least there's the problem of consistency.

This opens a bigger can of worms than this ticket can address, but it deserves some consideration in our thinking about the future of L10n and input methods on Sugar-using devices.

Let me pose the question differently. Should a Nepali-speaking, Devanagiri-script-writing child be forced to learn Latin character recognition to take full advantage of keyboard shortcuts?

At present, most hardware keyboards, including those created by OLPC DO contain the Latin characters allowing pattern-recognition learning, if not necessarily insight into why Copy is Alt-C and Cut is Alt-X.

Having used devices designed for the domestic Japanese market and not marketed in the US (Toshiba Libretto for example), I know I would be very upset if I needed to learn Kanji character recognition and keyboard positioning to use keyboard shortcuts.

Even the use of the nearly ubiquitous "F-keys" as shortcuts is slightly problematic on XO laptops as the top line of keys is not labelled with "F1 - F-12" and there is no obvious reason for a child that has never seen a full 105-key keyboard to suspect that the backlight and volume controls should do anything other than change the light and sound levels.

Thinking further ahead, what about the future of onscreen touch-activated virtual keyboards? Will a Maliit keyboard on an XO-3 be displayed on the screen with enough real-estate to show multiple possible characters represented by a key when used with modifiers (alt-gr, etc.)? Will there be room to always display the Latin character in addition to the native script character?

This is not an immediate concern, and yes it is "OLPC's problem", but as our largest customer / channel partner, we SHOULD be trying to anticipate their problems. In any event, it should be the subject of some careful forward-looking thinking and design considerations.

The solution is easy: Drop the mnemonic from the label. The accelerator alone achieves the purpose of providing a keyboard shortcut for the Run action. When setting the accelerator, Sugar will automatically cause a tooltip to be shown that contains the key combination to use; no additional hints required.

In addition the accelerator probably shouldn't be translated. It's the actual key combination that the user can use to access the function, not the string in the UI informing the user about the key combination. It needs to follow a  specific syntax; translating it naively would break its functionality (and possibly even the entire Activity). GTK already takes care of translating the keyboard combination when showing it on screen so it matches the labels on the keyboard.

That seems a reasonable approach for now.

It would be a good idea to allow individual users to customise the keyboard shortcuts, but that's a problem unrelated to translation. Language-specific keyboard shortcuts (accelerators) OTOH are likely to create much more confusion than they would be worth (by having the keyboard shortcut match the names of the actions in some more or less obvious way).

Agreed.

[cjl]

While I made the tongue-in-cheek statement that the XO-3 keyboard is "OLPC's problem", being forward compatible in general with touch-screen tablets is Sugar Labs' problem/challenge and as recent discussion about Sugar on iPads and iPhones has indicated, it is one we will be facing sooner rather than later.

[cjl]

I have opened a design ticket #3706 for the consideration of the design implications of onscreen keyboards. I did not mean to divert the main track of this ticket (Pippy) any more than necessary.

[RafaelOrtiz]

This bug was originally intended for translation issues, now it also involves mnemonics use.

In the end I agree with comment 15 by Sasha, the simple solution is drop mnemonics from labels.

This commit should tackle the issue:

 http://git.sugarlabs.org/pippy/mainline/commit/7fe2d30969235a426dc3c6fe0172dd4cab3f0d47

As for translation issues I'm closing this bug. Please open a new one for mnemonics/accelerators if necessary.

[cjl]

As for translation issues I'm closing this bug. Please open a new one for mnemonics/accelerators if necessary.

design ticket #3706