[Localization] [sugar] keyboard bindings for buttons and palettes

[Alexander Dupuy]

>
> 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.

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.

* 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.

* 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.

* 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.

* 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.

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.

@alex

-- 
mailto:alex.dupuy at mac.com