After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 90500 - *.kbd translation issues
*.kbd translation issues
Status: RESOLVED FIXED
Product: gok
Classification: Deprecated
Component: general
unspecified
Other other
: Normal major
: ---
Assigned To: David Bolter
David Bolter
2.4
Depends on: 46650 116526 126235 126237
Blocks: 122112
 
 
Reported: 2002-08-11 23:36 UTC by Jan Arne Petersen
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4


Attachments
Patch against intltool, for splitting output XML file (3.33 KB, patch)
2003-08-07 22:29 UTC, Abel Cheung
none Details | Review
patch to internationalize .kbd files. Also requires intltool patch from bugzilla (539.46 KB, patch)
2003-11-05 00:01 UTC, bill.haneman
none Details | Review
small intltool patch needed in addition to intltool patch for 116526 (1.97 KB, patch)
2003-11-05 00:09 UTC, bill.haneman
none Details | Review

Description Jan Arne Petersen 2002-08-11 23:36:48 UTC
The strings in the *.kbd and *.xam can't be translated yet.

As far as I know there are xml-i18n-tools which can extract them into the
*.po files.
Comment 1 David Bolter 2003-01-07 19:23:18 UTC
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.
Comment 2 bill.haneman 2003-06-06 13:01:37 UTC
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.
Comment 3 bill.haneman 2003-06-13 13:34:24 UTC
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!
Comment 4 David Bolter 2003-06-19 15:34:55 UTC
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.
Comment 5 bill.haneman 2003-06-23 08:41:45 UTC
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.
Comment 6 bill.haneman 2003-06-29 12:01:51 UTC
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.
Comment 7 bill.haneman 2003-06-29 14:26:51 UTC
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.

Comment 8 bill.haneman 2003-06-30 17:03:53 UTC
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.
Comment 9 bill.haneman 2003-06-30 17:18:18 UTC
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.
Comment 10 bill.haneman 2003-07-02 15:24:08 UTC
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

Comment 11 bill.haneman 2003-07-02 15:25:01 UTC
looks like with a little help we can get this dealt with for 2.4,
which would be great!
Comment 12 Calum Benson 2003-07-02 18:06:36 UTC
Downgrading as per yesterday's triage meeting.
Comment 13 Calum Benson 2003-08-07 16:08:46 UTC
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)
Comment 14 Abel Cheung 2003-08-07 22:27:49 UTC
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?
Comment 15 Abel Cheung 2003-08-07 22:29:19 UTC
Created attachment 19017 [details] [review]
Patch against intltool, for splitting output XML file
Comment 16 Abel Cheung 2003-08-11 14:42:02 UTC
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?
Comment 17 David Bolter 2003-08-11 19:08:12 UTC
Either way is fine with me, as long as it all works.
Comment 18 Abel Cheung 2003-08-11 19:21:54 UTC
So .xml.in is used as it's already there. It will be available in
intltool 0.27 (will be released shortly).
Comment 19 David Bolter 2003-08-12 15:13:58 UTC
Abel,

This has broken gok for me.  I am currently looking into why the
generated xam files seem to have caused problems...
Comment 20 David Bolter 2003-08-12 15:21:46 UTC
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?
Comment 21 Abel Cheung 2003-08-13 02:12:57 UTC
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.
Comment 22 Abel Cheung 2003-08-13 03:50:18 UTC
remove GNOMEVER2.0 keyword. *.kbd files localization is dependent on
intltool's ability to split localization into various files as well.
Comment 23 David Bolter 2003-08-13 14:05:58 UTC
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?
Comment 24 bill.haneman 2003-09-09 13:19:31 UTC
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
Comment 25 bill.haneman 2003-11-04 18:25:01 UTC
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

Comment 26 bill.haneman 2003-11-05 00:01:14 UTC
Created attachment 21197 [details] [review]
patch to internationalize .kbd files.  Also requires intltool patch from bugzilla
Comment 27 bill.haneman 2003-11-05 00:06:57 UTC
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

Comment 28 bill.haneman 2003-11-05 00:09:10 UTC
Created attachment 21198 [details] [review]
small intltool patch needed in addition to intltool patch for 116526
Comment 29 Kenneth Rohde Christiansen 2003-11-05 00:18:45 UTC
The intltool patch looks fine to commit - when the other intltool
patch is committed.
Comment 30 bill.haneman 2003-11-05 00:25:18 UTC
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?)
Comment 31 bill.haneman 2003-11-11 01:37:14 UTC
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.
Comment 32 bill.haneman 2003-11-11 13:13:13 UTC
fixed in cvs.
Comment 33 David Bolter 2003-12-03 14:03:10 UTC
WOOHOO!!!