GNOME Bugzilla – Bug 130998
add gok translator comments to XML files
Last modified: 2004-12-22 21:47:04 UTC
Problem is that translator comments (as it turns out) must be one the *physical line* immediately preceding the "_()" macro in C source, not the "logical" C line. So gok needs a good scraping through, searching for instances of _() where the translator comment is either absent or misplaced. Also we need translator comments for some XML strings, but that's another issue... may not be a way to do this yet. We could hack around the problem with a dummy ".h" file that's in POTFILES.in but not a dependency of the sources, etc. but that's very ugly. However if we have really difficult strings (like the "N" and "E" strings in move-resize.kbd, which are locale-appropriate abbreviations for 'North', 'East', etc.) then this hack may be worth doing anyway because otherwise translators will really get frustrated with these sorts of GOK strings in the ".kbd" files.
in particular, we urgently need to fix the multiline translator comments for gok_keyboard.c's alphabetic and frequency keyboards, by interleaving them in the C call (or making the C call a single line). Both are ugly, but there you have it.
I understand the interleaving but not the single line fix. I am fine with this quick fix because of the urgency. It would be nice to a fix to a logical (vs physical) parse. Feel free to modify and commit this change. Or let me know and I can do it.
I've fixed the offending comments in gok-keyboard.c We should have a look at the output of gok.pot at some point to see if any of the C-source strings need to be commented. Of course doing it in interface.c would be a problem since it's generated code. Ugh, we really need to change that.
David could you please have a look at the remaining translator strings? thanks.
Investigating this, I notice lines in gok_page_accessmethod.c like: pWidget = gtk_frame_new (_(pControl->String)); Yoikes, surely that is not good? I'll proceed to fix, unless I hear complaints here...
well it's _possible_ that such code is OK, so please post patches/discussion before tacking that specific issue.
changing summary since I think the existing comments are getting picked up.
I think what we need now is a way to provide translator comments for libglade and *.xml.in/*.kbd.in files.
I think our translator comments are currently pretty good except for the XML files. Now that intltool supports XML translator comments, we can start putting them into the .kbd.in and .xam.in files.
bumping up priority as string freeze is approaches for some internal releases.
Bill, I'm happy to slog through this. Can you give me details or an example "XML translator comment" just to be sure I'm on the same page?
sadly, I can't give an example offhand. Perhaps googling around, or checking the ChangeLog for intltool will help?
Just added a dependency for reference.
I'm looking after this one.
Note to self: README-TRANSLATORS will need to be updated.
Thanks David. Just as an aside: in particular, translator notes are required for strings that are and/or need to be short, abbreviations, odd strings out of context, etc. IOW anything that's not readily translatable out of context. IN particular, short strings are a problem, xlator comments often are needed to indicate the context, whether the word is noun or verb, etc. etc. The .kbd.in files are a serious translation nightmare, so almost every translatable element should have a comment giving context. Probably in most cases we'll need to say something like "a short string blah blah blah" too, or else we'll get strings too long to put on the GOK keys.
Yeah, I'm on the same page.
Created attachment 28436 [details] [review] diff for discussion Bill, do you remember our plans for alphabet.xml.in? (I borrowed your translator comments from gok-keyboard.c) Do we want to deprecate gok_keyboard_add_keys_from_charstrings and start using the xml file?
David: the strings are newer than the XML file. I believe we came to the conclusion that the add_keys_from_charstrings method was easier to translate (in most locales anyway).
Created attachment 31147 [details] [review] patched kbd.in files and the translator readme. I'm not sure of my wording for the translator comments and so this will need review I am sure. Also, this patch as is, breaks code freeze in mouse.kbd.in because i adopted some images in place of the directional key labels. I think this is a better solution that asking translators to deal with NW N NE W E SW S SE directions...
David: I think we need to split this into two patches then, one of which can be applied now, and the other of which will require more negotiation with the release team.
Makes sense, I'll whip together a version of mouse.kbd.in that only adds comments.
Created attachment 31151 [details] [review] this patch does not break code freeze.
Created attachment 31152 [details] [review] this is a longer term fix for mouse.kbd.in post 2.8.0 code freeze
David - I like the "no freeze breakage" patch. I'd use 'abbreviation' in a couple of places instead of "short label", i.e. "ins" and other Gok labels which aren't complete words. Would you commit, with that minor tweak?
BTW David, - after that commit, perhaps we should open a new bug RFE - "gok to use images rather than labels for movement keys", and leave that one open till post-2.8; we can then close this bug.
Comment on attachment 31151 [details] [review] this patch does not break code freeze. Committed with Bill's suggested edits. So not exactly as shown.
Comment on attachment 31152 [details] [review] this is a longer term fix for mouse.kbd.in post 2.8.0 code freeze duplicated in new bug 151606
Bill, done, and done! :-)