The following string cannot be localized: "Special keys (Ctrl+Alt+<key>) handled in a server" Confirmed based on Crimean Tatar (Crimean Turkish) and French locales. If this is a bug in gettext, this can be reported there. But if using < and > characters directly, w/o using character entities for them, works, then that change should be made in xkeyboard-config project. P.S. I haven't tried using < and > in translation directly, but implicitly expecting translators to know this probably wouldn't be acceptable. If such a work-around works, and is required, then a comment should be added to inform translators of this.
It is not a bug in gettext. This goes from base.xml.in - it is standard XML convention for these symbols (otherwise a parser would parse them as XML tag <key>). These XML entities are also used in cz(bksl) description: "With <\|> key". Since intltool (the preprocessor for feeding XML to gettext) supports translator comments, I will probably add them (of course, after the release tomorrow). If you have any proposal on some clear wording for these comments - please put them here. Something like : <!-- The < and > entities are used to indicate "less-than" and "greater-than" characters. -->
(In reply to comment #1) > It is not a bug in gettext. I think the answer to this depends on whether gettext expands original string's entity references itself, or whether the UI parser does that. In the former case, it would be gettext issue, in the latter case it would be UI's issue, but this project would need to document this and make it easy for any UI to be aware of it. > Since intltool (the preprocessor for feeding XML to gettext) supports > translator comments, I will probably add them (of course, after the release > tomorrow). If you have any proposal on some clear wording for these comments - > please put them here. Something like : > > <!-- > The < and > entities are used to indicate "less-than" and > "greater-than" characters. > --> > I went ahead and gave it 1.5 hours: 1. as i expected ahead of time, just using < and > in translations isn't enough: gettext fails to find a match to begin with, which goes off of the default locale. 2. my next theory was to use a CDATA section, but for some reason even that did't work: i tried changing PCDATA to CDATA and ANY, and no luck: something breaks down, possibly in the parser. So most likely, something will have to change in the UI parsers, regardless of whether something changes in xkeyboard-config or not. For instance, the following hypothesis might be true: a. even w/o any changes in xkeyboard-config, if the UI parsers obtain original strings with a parser that doesn't expand entity references, and then obtain the translations, and only then expand entity references as a separate step, the issue might be resolved. b. Of course, if there's a way to get CDATA sections to work here, it might be a better approach. P.S. In either case though, either UI developers, or (if CDATA approach is made to work), translators, will apparently need to be informed via comments (for developers possibly in README) that they need to watch out for this. P.P.S. Unfortunately, I'm unlikely to have any more time to look into this issue, cause i have higher priority things to work on.
Actually, after playing a bit, I think it can be fixed in libxklavier, no need to bother translators.
Should be fixed in libxklavier CVS. Could you please check?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.