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

List:       kde-devel
Subject:    Re: Translating custom XML format
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2009-03-23 22:59:10
Message-ID: 200903232359.11165.aacid () kde ! org
[Download RAW message or body]

A Dissabte, 21 de març de 2009, Vladimir Kuznetsov va escriure:
> On Wednesday 04 February 2009 01:47:56 Albert Astals Cid wrote:
> > A Dilluns, 2 de febrer de 2009, Vladimir Kuznetsov va escriure:
> > > 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 ?
> >
> > Hi Vladimir, the Fantastic Three of i18n (Chusslove, Pino and me) are
> > working on it, which means i'm trying Chusslove and Pino not to kill
> > eachother while i steer conversation to a feasible solution.
> >
> > Hope to have a better answer by the end of the week.
>
> Any news on this topic ?

I did not say which week it would be ;-)

No serious, that week my HD got trashed and i was off the internet for 2 weeks 
and i'm still trying to catch up, I've not forgotten about it.

I'm really really sorry for not keeping up my promises.

Albert

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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