Lokalization for KDE AppStream AppData files

Matthias Klumpp matthias at tenstral.net
Tue Feb 25 17:45:52 GMT 2014


2014-02-25 16:15 GMT+01:00 Thomas L├╝bking <thomas.luebking at gmail.com>:
> Notice that I don't care much about i18n at all (so i don't intend nor could
> argue), just curious:
>
>
> On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote:
>>
>> Hi again!
>> I talked to some people, and it looks like merging the translation
>> back into one file using existing tools is not possible.
>
>
> From what i understood the issue is that intltool needs a _prefixed tag to
> separate translatable from untranslatable elements.
Yes
> Would not <p lang="x"> (assuming x to be some invalid lang ID - i do not
> care about i18n...) be sufficient in that regard?
> Is intltool really incapable of selecting a specialized lang as translation
> source?
Well, it's not how that XML stuff is translated... Also, we need a
translation template/fallback-tag for each localized tag, so it is
absolutely a sane thing to do.
There also is itstool, which resceives a definition of translatable
elements in order to translate XML, which is pretty neat. However, it
expects an untranslated XML-file as input and returns the tramslated
version. If you give it a translated file, it duplicates tags there
(which is even documented), and there seems to be no option to turn it
off.
All people I asked either asked why I couldn't simply store the
template somewhere or why I would want to translate a translated file
;-) So, it appears there is no "standard" way to handle this case, and
I see no disadvantage in having Scripty commit a trsnalted file as
separate file. It's a bit... magic and people should be aware of that
when they add AppData, but apart from that I don't see disadvantages.
If someone writes an XML translator which does whatever needed to
translate translated files, I'd be happy with that as well, but I
think doing that would be a waste of time.
Cheers,
   Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/




More information about the kde-core-devel mailing list