In the case of .kbd (keyboard) files it is best to recreate them as
the layout of keys etc. will also likely need to be changed.

I am not sure David - for everything other than the "qwerty" keyboard,
that is, we probably do want translators to be able to help us.  I
think the priority/severity should be bumped up, especially now that
we're aiming for 2.4.

I don't know whether we can do anything about this before the string
freeze however.

I think this should be a high-priority bug - at least we need to come
up with a means of internationalizing .kbd keyboards before 2.4!

Bill, is there an i18n expert we can get advice from?  I have some
ideas on how we might proceed here but they are uneducated.

David, I spoke to a number of people about this at GUADEC.  These
files can be translated in their current state (by adding them to
potfiles.in,  I believe), but there are potentially problems with
using the normal XML internationalization approach for GOK.  In any
case we need to work with the existing gnome localization project
framework in order for the work to get done (e.g. so that the strings
are 'visible' to translators and flagged so that they know
translations need to happen).  

Whatever we do it's 90% certain that we need to do it within the
"intltool" framework.  The problem with the "usual" XML translation
approach is that all the translated strings end up in the XML file in
separate XML elements, on a per-locale basis.  This could mean a
hundredfold increase in the number of elements in the XML files - not
necessarily good if the files are in any way hand-edited, or from a
performance point of view.

I think it'd be fine to use the standard intltool approach for the
.xam files, it's only the .kbd files that I think may warrant special
treatment.

David - I've got the "standard" XML translation approach working for
the .xam files, by replacing them with .xml.in files which are
used according to build rules in Makefile.am to merge translations in
to the target *.xam files.

However, at the moment only the GOK:description fields can be
localized in this way since attributes are AFAIK not localizable using
intltool.  Therefore all the .xam string attributes are still not
translatable.  I think the fix for this is to change the .xam format
so that the translatable labels associated with the elements are
actually element text content rather than attributes.  Ugh.

Do you think this kind of change (to the .xam format) is do-able for
2.4?  It's "sort of" an API change but I think it would be allowed by
the release team since it's semi-private API and also important to
localization.

David, I worked out how to internationalize the .xam files, including
attributes.  I was just ignorant :-)

if you prefix the attribute name in the .xml.in file with an
underscore, the attribute's string gets marked for translation and
merged.  If you need to internationalize CDATA then you put the
underscore in front of the element name.

So I've marked up the attributes in the four currently-supported XAM
files and am re-disting.

This leaves the issues with the *.kbd files open - we'd like to have a
means of splitting rather than merging the XML files with intltool-merge.

noted dependency on intltool-merge bug.
If that bug is fixed, recent patches to GOK should make this work.

Note that before closing this bug, in addition to fixing the
intltool-merge problem with XML attributes, GOK needs to use
gok_scanner_find_node in place of gok_keyboard_find_node, etc. for all
the localized nodes in gok-scanner.c

looks like with a little help we can get this dealt with for 2.4,
which would be great!

Downgrading as per yesterday's triage meeting.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

The following patch is a quick hack on intltool-merge for splitting
file issue. A '--split-xml' option is added, indicating that output
XML file should not be monolithic, but seperated into individual
files. I tried it on .xam files and it seems to work, but definitely
not polished yet.

This is a proof of concept that, once intltool supports *.kbd files,
they can be splitted as well.

One question though. When writing output file, is it desired to write
each file for one language into individual subdir, or just write
everything to current directory?

Created attachment 19017 [details] [review]
Patch against intltool, for splitting output XML file

I'd want to propose adding an INTLTOOL_XAM_RULE makefile rule for
processing .xam files, just like all the INTLTOOL_*_RULE currently do.

Currently .xam files are generated from .xml.in files. Is it desirable
to change it to .xam.in instead, or just keep using .xml.in?

Either way is fine with me, as long as it all works.

So .xml.in is used as it's already there. It will be available in
intltool 0.27 (will be released shortly).

Abel,

This has broken gok for me.  I am currently looking into why the
generated xam files seem to have caused problems...

Abel,

The _displayname attribute of GOK:accessmethod in xml.in files is not
getting processed, and appears as _displayname in the xam file.  This
breaks gok.  I can perhaps add a nasty workaround, but do you think
this is fixable soon?

Thanks for pointing out, sorry that I've been paying few attention to
the XML tag attributes.

It's #116526, which has not been fixed yet (and this bug depends on
it). I'll tackle on it if nobody is going to try.

What's the best way to make attributes localized into all languages
and placed in the same file? (or is this possible at all?)

Alternatively, if the desired fix is just to transform "_displayname"
-> "displayname", then it can be done quickly.

remove GNOMEVER2.0 keyword. *.kbd files localization is dependent on
intltool's ability to split localization into various files as well.

Abel,
Thanks for all your work in this effort!  Please note that the
workaround is in cvs.  You will have to check a generated .xam file to
see if the _displayname still exists. As for the best way to handle
localization of attributes, I am not the best person to ask...  Could
you please take that discussion to gnome-i18n@gnome.org?

What's the status of the intltool bugs that this depends on?

Once those are sorted, instead of a nasty hack to handle only one of
many attributes ("displayname"), we can actually localize all the GOK
.kbd files.  Without having localizations for those files, GOK isn't
very useful in non-English locales.

- Bill

I am working on a patch for this bug, which:

* uses a new intltool macro, INTLTOOL_KBD_RULE
  (needs to be added to intltool)

* uses new (patch-only) intltool attribute merging fix from
  Brian (will need to wait for the patch to be revised and put
  into CVS before applying this patch)

* creates the *.kbd files from *.kbd.in files

* marks the user-visible strings in the *.kbd files
  for translation.

Note that the following keyboard files are not marked for
translation, because either they aren't used by default in GOK,
or they are not translatable by simple gettext() methods:

  alphabet.kbd
  qwerty.kbd
  Keyboard.kbd
  manage.kbd
  test.kbd

Created attachment 21197 [details] [review]
patch to internationalize .kbd files.  Also requires intltool patch from bugzilla

The above patch needs a ChangeLog entry; that'll give me something to
do while waiting for the intltool patches for 116526 to be committed
to cvs :-)

Note that the patch:

* marks *.kbd _GOK:labels for translation
* uses INTLTOOL_KBD_RULE (new)
* increments configure.in to 0.9.2
* puts the new *.in->*.kbd rules in Makefile.am
* marks some warnings for translation
* adds the *.kbd.in files to potfiles.in

Created attachment 21198 [details] [review]
small intltool patch needed in addition to intltool patch for 116526

The intltool patch looks fine to commit - when the other intltool
patch is committed.

Note that the intltool patch's --multiple-output seems to be broken,
or I don't know where the multiple outputs are supposed to go.  You
may wish to hack this out of the patch for testing for the moment (i.e
omit the --multiple-output option until further notice from this patch?)

multiple-output is fixed now.  We're fine tuning it... despite the
fact that 46650 is still open pending a final commit, I think this bug
is now closeable since we've marked the *.kbd files for translation
and have a means of reading locale-specific files.  I'm committing a
Makefile.am fix to GOK also so that the translated files get
installed, hopefully tomorrow.

fixed in cvs.

WOOHOO!!!