A Dimarts, 24 de març de 2009, Vladimir Kuznetsov va escriure:
> On Tuesday 24 March 2009 01:59:10 Albert Astals Cid wrote:
> > 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.
>
> Not a problem, I really understand you. Currently I have almost no time
> myself (last year at the university, etc.). And we still have lots of time
> until message freeze :)
>
> A bit later (when I have a time) I'll blog about by extractxml solution. Is
> it OK ?

Yeah. 

Albert

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