[Bugs] #3698 Pippy UNSP: Pippy has translation issues

[Sugar Labs Bugs]

#3698: Pippy has translation issues
------------------------------------------+---------------------------------
    Reporter:  manuq                      |          Owner:  dirakx     
        Type:  defect                     |         Status:  new        
    Priority:  Unspecified by Maintainer  |      Milestone:  0.96       
   Component:  Pippy                      |        Version:  Unspecified
    Severity:  Unspecified                |       Keywords:  12.1.0     
Distribution:  Unspecified                |   Status_field:  Unconfirmed
------------------------------------------+---------------------------------

Comment(by cjl):

 Replying to [comment:16 sascha_silbe]:
 > Replying to [comment:14 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 [http://developer.gnome.org/gtk/stable/gtk-Keyboard-
 Accelerators.html#gtk-accelerator-parse 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.

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/3698#comment:19>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system