[sugar] [Localization] keyboard bindings for buttons and palettes
Tomeu Vizoso
tomeu at tomeuvizoso.net
Mon Mar 3 05:59:33 EST 2008
On Fri, Feb 29, 2008 at 7:54 PM, Alexander Dupuy <alex.dupuy at mac.com> wrote:
> >
> > I'm not sure translatable accelerators are a good idea. I see the
>
> > advantages, but it also means you are "screwed" if you switch
> > language. Eben?
> >
>
> >
> > Me neither, that's why I left it at the discretion of the language
> > administrators. I think that errors in translating labels can be as
> > bad as in accelerators.
> >
> > I can see how some languages may prefer to not translate accelerators.
> > But I guess for some languages/keyboards, the english accelerators can
> > be suboptimal.
> As a native English speaker who uses a Spanish localization of Fedora on
> a daily basis, it was a bit hard at first to get used to the different
> accelerators for localized applications. However, that's not an issue
> for the kids who are the target audience for this.
>
> I have to wonder, though, if it really makes sense to carry this part of
> the classic WIMP interface forward into the 21st century Sugar - while
> developers may find keyboard accelerators handy, because they are used
> to them, do the kids with no prior exposure to this concept really find
> it useful? Even among adult North Americans with some (but not
> necessarily a lot of) computer experience, I often watch people
> navigating the menus quite oblivious to (or at least uninterested in
> using) the keyboard shortcuts. This is especially true for the
> Windows-style "Alt-E_xit" menu navigation stuff, which I hope Sugar will
> avoid, except as necessary for disability access.
You may be right in that "normal" users don't use accelerators in
"normal" desktops. But our user base will have some peculiarities and
our software too. Perhaps accelerators will make more sense in Sugar
because we can provide more consistency and better localization?
Also, we hope children will use the laptop more extensively than most
casual users in developed countries. You can see a very big difference
in how a pencil is used between someone who rarely uses it and someone
who uses it as a frequent tool.
> In any case, if this is done, it would be a good idea to avoid a couple
> of serious problems with keyboard shortcuts and their localization.
Yes, we probably can provide a different approach for shortcuts for
different languages.
> * Something that I continue to find extremely annoying is the
> inconsistency between and even within applications, a few of which use
> localizations (e.g. OpenOffice uses Ctrl-G (guardar) instead of Ctrl-S
> (save) - but nonetheless uses Ctrl-Shift-S for "guardar como" (save as)
> - go figure). However, most applications don't localize accelerators,
> so for half the applications you use Ctrl-S for guardar. Consistency
> across all activities (for a given localization) is critical if this is
> to be at all useful.
Totally agreed.
> * For locales that have alternate alphabets (e.g. Arabic, Cyrillic) as
> well as Latin, it would be very annoying if you had to switch to the
> Latin alphabet to use a shortcut - localization can help with that - but
> it would still be annoying if you were in Latin for some reason and had
> to switch to Cyrillic to use the localized shortcut. This implies that
> you want to have *two* keyboard shortcuts (one in Latin, and one in the
> native alphabet; both mapping to the same physical key). Localization
> alone can't accomplish this - it requires either a very clever
> application that knows the keyboard type and details of the keyboard
> layout, or some extra work on the internationalization to add a hidden
> second shortcut that can be used for Latin shortcuts when the primary
> shortcut uses a non-Latin alphabet. I suppose it could also be done
> with appropriate keymapping magic so that the Ctrl modifier always
> forces Latin, but this would get very tricky, and complicates things
> somewhat for the localizers.
Users will switch keyboard layouts frequently? Cannot we just
translate shortcuts to other characters in the cyrillic or arabic
layouts so they are used similarly to the latin one?
> * For locales that use a SCIM input method to map multiple keypresses to
> a particular character (or a single keypress to multiple characters,
> e.g. in Khmer), things start getting a lot more complicated, and I'm not
> even sure what all the possible problems may be. It's certainly clear
> that in these locales the benefit of a keyboard accelerator is going to
> be pretty limited, and it would probably be a good idea to allow
> localizers not only to choose alternate accelerators, but also to choose
> to omit (or at least hide) the accelerator information entirely.
Right, I would like to hear opinions from users of those input systems.
> * When a lot of accelerators are in use, mapping actions to distinct
> characters that have any kind of semantic or mnemonic association with
> the action is quite tricky. However, what is tricky in English often
> becomes very difficult or impossible in another language, especially if
> there are multiple sets of accelerators in effect at the same time
> (global accelerators + activity-specific accelerators + button
> accelerators on a dialog). Rather than be forced to choose meaningless
> characters for these accelerators, localizers should be able to enter a
> special string that disables the specific accelerator (would an empty
> string have this effect?) and activity developers should be strongly
> encouraged to limit use of keyboard accelerators to no more than seven
> or eight of the most useful and common activities.
Agreed.
> All in all, while I wouldn't put up a red flag, from a localization POV
> I would raise a yellow flag (proceed slowly, and with caution) about the
> addition of this feature.
Sure. Thanks a lot for your comments.
Tomeu
More information about the Sugar
mailing list