GOK internationalization

[Bill Haneman <bill haneman sun com>]

Hi Folks:

As we near UI Freeze for gnome-2.4, we are triaging remaining bugs for 
GOK, the Gnome Onscreen Keyboard suite.  As you may or may not know, GOK 
has some unique internationalization aspects.  Bug 90500 addresses one 
aspect of the issues:

> http://bugzilla.gnome.org/show_bug.cgi?id=90500

GOK's internal strings are already translated reasonably well - at least 
with regard to messages and the Properties dialog, etc.  However GOK 
relies on XML files for its "access methods" and its static onscreen 
keyboards (the dynamic onscreen keyboards are built at runtime and 
should be appropriately internationalized already).

We just added the currently-used access method files to POTFILES.in 
(*.xam targets created from *.xml.in files).  However the access method 
XML syntax relies on user-visible string attributes (rather than element 
CDATA); we are considering whether we have time to fix this for 2.4 so 
that all of the user-visible strings in the *.xam files are 
translatable.   Release team, is this change (to private API) something 
we can make before 2.4, in view of the (positive) internationalization 
impact?

Also, and more interestingly, GOK's static keyboards are read from XML 
files.  These are a combination of generic keyboards such as 
"launcher.kbd", and locale-specific keyboard such as "alpha.kbd" and 
"Keyboard.kbd".  The locale-specific keyboards cannot localized using 
the usual intltool techniques since their layout as well as their labels 
will vary from locale to locale (more on this later).  However the 
generic keyboards are, theoretically, localizable using the standard 
intltool-merge rules for XML.

However, many of these static XML files are intended to be at least 
occasionally user-editable.  We are not sure that the resulting 
proliferation of elements in the files is the best thing for the user - 
though we can change our "keyboard editor" to make this transparent to 
the user, users who wish to edit the keyboards directly in a text editor 
might find this daunting.  Also we are not sure, in the absence of 
benchmarks, what the performance impact of the larger .kbd files might be.  

In the case of locale-specific keyboards, we expect that the best 
approach for GOK, which stores these keyboards in a gok-specific data 
directory (i.e. $prefix/share/gok/*.kbd), will be to create 
subdirectories for each locale ($prefix/share/gok/keyboards/C 
$prefix/share/gok/keyboards/fr_CA etc.).  In view of that fact, we are 
considering the alternative for our static keyboards, of creating 
separate XML files per-locale rather than merging all the localized 
elements into one XML file.  We think that the latter approach would be 
better for the user, but are not sure who would be able or willing to do 
the necessary intltool hack to implement this alternative merge technique.

We are "firmly on the fence" about this - we think separate XML files 
would be better, but are not sure we should punt GOK 
internationalization until 2.6 because of it.  So we are asking both the 
release team and gnome-i18n for feedback.

* if R-T thinks we're too late to tweak GOK's internal API to facilitate 
internationalization for 2.4
  (i.e. changes to the .xam format and a small change to the internal 
.kbd import algorithm to take
   the current locale into account), then we will punt.

* on the other hand, if R-T thinks localization of GOK is desirable for 
2.4, we would consider using
   the "classic" XML intltool-merge technique for the generic keyboards.

* if someone in gnome-i18n is willing to tweak intltool for create split 
xml files instead of merged ones,
  we'd like to wait for this change if it's likely to happen in time for 
our 2.4 release.

* In either case, we solicit suggestions from gnome-i18n as to how to 
make it easier for
   translators to help localize our "locale-specific" keyboards - for 
instance, "qwerty.kbd"
   which is a static physical compose keyboard based on the physical 
layout (we also have the
   ability to create this on-the-fly from XKB so this is an optional 
feature, GOK can display
   non-latin keyboards without it).  Similarly we have "alpha.kbd" which 
is an alphabetically-arranged
   keyboard, and we will want to provide for each locale a "weighted" 
keyboard which has the most
   frequently used characters at the upper-left and the least used 
characters at the lower-right.
   How can we alert translators to the need to translate these 
keyboards, and make it easier for them?

Thanks very much for reading this far and for your suggestions regarding 
how we should proceed both for 2.4 and future.

regards,

Bill