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

List:       kde-devel
Subject:    Re: Translating custom XML format (initial implementation for Step)
From:       Vladimir Kuznetsov <ks.vladimir () gmail ! com>
Date:       2009-02-04 20:42:52
Message-ID: 200902042342.52299.ks.vladimir () gmail ! com
[Download RAW message or body]

Hello,

I've just commited (r921337, but r921338 temporary disables it) my draft 
implementation of extraction/putting back strings from XML files. It requires 
translators to create one svn:external link:

/trunk/KDE/kdeedu/step/step/data ->
        /trunk/l10n-kde4/<lang>/data/kdeedu/step/data

and to include that directory from parent CMakeLists.txt. Everything other is 
handled automatically.

If something else will be implemented KDE-wide, I'll happily switch to it, or 
alternatively I could help adopting my implementation for others.

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.
>
> Albert
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<


-- 
      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]