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

List:       kde-i18n-doc
Subject:    Re: [Kde-extra-gear] Yet another KEG translation problem . . .
From:       Rinse de Vries <rinsedevries () kde ! nl>
Date:       2005-06-04 7:44:00
Message-ID: 200506040944.01100.rinsedevries () kde ! nl
[Download RAW message or body]

Op maandag 30 mei 2005 20:12, schreef Jeroen Wijnhout:
> Tom Albers wrote:
> >Op zondag 29 mei 2005 10:25, schreef Jeroen Wijnhout:
> >>Hi,
> >>
> >>Ok, this problem bit me for the latest release of Kile, for the first
> >> time, but it is pretty annoying:
> >>
> >>Suppose you want to support more than the latest KDE release, not
> >> uncommon for extragear apps. Let's say KDE 3.3 and KDE 3.4. Now suppose
> >> that after the 3.3 release a new translator is working on your docbook
> >> file and adds his/hers entity to the translated docbook. At this point
> >> an extragear app is screwed, because this new entity is not available on
> >> 3.3 systems, only on 3.4 systems. This means that make fails, which is
> >> generally bad ;-(
> >>
> >>Solutions? Hand editing the docbooks . . . Perhaps somebody can come up
> >>with something better?
> >
> >For an entity to work it has to be available on the users computer. So you
> > can only use it when you are sure it is there. For extragear (and
> > koffice) entities should be used very carefully or not at all.
>
> Exactly, but is this common knowledge among the translators?
>
> >Language coordinators should verify that.  If you run into that problem,
> > you should address the coordinator and not hand edit the docbook file.
> > The docbook file is an automatically generated file and your change will
> > get lost sooner or later.
>
> Right, Rinse can you fix it, please?

I'm not the coordinator of the docs :)
I'll CC to our mailinglist, so that Sander can fix this.

>
> >As long as entities are part of the official kde releases, there is no
> > other solution I can think of, except for one complicated one, by merging
> > entities into the docbook, but I don't even know if that is going to
> > work.
>
> xmllint is capable of doing this (option --noent).
>
> best,
> Jeroen
[prev in list] [next in list] [prev in thread] [next in thread]