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

List:       kde-i18n-doc
Subject:    Re: [RFC] Documentation, take 2
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-12-09 16:35:26
Message-ID: 200512091735.26304.nicolasg () snafu ! de
[Download RAW message or body]

On Friday 09 December 2005 00:28, Erik Kjær Pedersen wrote:
> So here is a concrete suggestion.
>
> There really is no point in translating outdated docbooks. Should it happen
> that a docbook describes a feature of the future that is better than being
> completely obsolete.
>
> So docbooks should only be translated one place, in trunk.
> I would do away with home/kde/branches/stable/l10n/templates/docmessages
> and home/kde/branches/stable/l10n/xx/docmessages
> but keep home/kde/branches/stable/l10n/xx/docs
> for the language xx.
> When I have finished translating some docbooks in trunk, I would then
> backport them to home/kde/branches/stable/l10n/xx/docs
>
> If I am very far behind it is actually not an advantage to have the
> documentation there, so I could remove the docbooks when I am very far
> behind.
>

> In trunk the tag should be moved to the present stage of the docbooks once
> a week, and then immediately the pot-files should be produced and the
> merging should be done. It is quite frustrating when the pot-files and the
> docbooks are out of synch.

That would mean changing the external reference each week.

However when you change an external reference svn update has the tendency to 
re-fetch everything, instead of just updating.

>
> This way the docbooks never would have to be frozen, but they could do
> something similar with the English docbooks, namely have them two places
> and only occasionally backport.
>

> Another problem is the problem with koffice and the extragear programs.
> You can never introduce a new entity because there is no way to get that
> new entity put into the old versions of kdelibs that they only want to
> depend on. Entities are good because they give uniformity to the docbooks.
> Maybe that could be solved by having po2xml expand the entities when the
> translated docbooks get produced.

I do not think that po2xml can be fixed that way.

However xmllint seems to have --noent. Perhaps somebody could experiment with 
this parameter. Perhaps we can check the file with xmllint too and therefore 
avoid another pass on the DocBook file.

>
> Erik

Have a nice day!


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