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

List:       kde-i18n-doc
Subject:    Re: [RFC] Documentation, take 2
From:       Erik =?iso-8859-15?q?Kj=E6r_Pedersen?= <erik () binghamton ! edu>
Date:       2005-12-08 23:28:15
Message-ID: 200512081828.16226.erik () binghamton ! edu
[Download RAW message or body]

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.

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.

Erik

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