[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Translating custom XML format
From:       Vladimir Kuznetsov <ks.vladimir () gmail ! com>
Date:       2009-02-02 19:31:17
Message-ID: 200902022231.18109.ks.vladimir () gmail ! com
[Download RAW message or body]

Hello,

On Monday 02 February 2009 20:16:16 Chusslove Illich wrote:
> > [: Vladimir Kuznetsov :]
> > In worst case I could write scripts for extracting strings to .po files
> > and putting them back myself, but will it be possible to instruct scripty
> > to run my scripts ?
>
> KDE's repo automatization at the moment has no provisions for extracting
> arbitrary XML files. Every particular XML type (e.g. UI files) is handled
> in its own way, and documentation Docbook files especially so (as you could
> glean from Burkhard's message).
>
> So it is the worst case that you'll have to go for. Once you have the
> script to extract your custom XML files into a POT, for Scripty to pick it
> up you simply have to add the conversion line to Messages.sh. One popular
> way of doing it, in order to avoid creating POT manually, is to extract XML
> into a dummy C++ file, just like it's done with $EXTRACTRC ... >rc.cpp line
> for UI files.
>
> As for using the POs once translators make them. Do you have a specific
> reason why you want to have localized XMLs, and thus have to do back-
> conversion step? Could it possibly go through the code, such that after
> reading user-visible XML fields you pass them through i18n calls? Then you
> wouldn't have to do anything past extracting strings in Messages.sh. E.g.
> KGeography and Marble do it this way.

Actually I have two different set of files and two different reasons:

1. Context-documentation files. There are lots of such files and each file 
contains relatively big piece of HTML code that is supposed to be translated 
as on big single entity. AFAIK gettext is not designed to handle large 
strings, is it ?

2. Example files. I want them to be user-editable: the user may use them as a 
base for creating his own files by opening, modifying and saving to another 
location. System-wide translation database obviously won't and shouldn't 
interfere with copied file. Another reason is that users should be able to add 
(and even pre-install system wide) more example files themself in one or 
several languages without dealing with KDE translation system.

It seems that CMakeLists.txt in l10n-kde4/<lang>/data/package/appname are not 
autogenerated. Is it a good idea to put the code for localized XML generation 
into it ?

-- 
      Best Regards,
        Vladimir
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]