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

List:       kde-i18n-doc
Subject:    Re: Errors while packaging koffice l10n.
From:       Erik =?utf-8?q?Kj=C3=A6r_Pedersen?= <erik () binghamton ! edu>
Date:       2006-03-26 23:06:29
Message-ID: 200603261806.30163.erik () binghamton ! edu
[Download RAW message or body]

Fredag 24. marts 2006 03:46 skrev Tom Albers:
> Ah, what a mess.....
>
> In the end it is the responsibility of the language team to test if there
> docbook compiles. What does not compile, can not be shipped.

I want to make sure that everybody understands what the problem was, and the 
solution is, before we leave this topic.

kexi is the first program to use the entitity underLGPL in all of kde's 
documentation. The various translation teams have to edit catalog and 
lang.entities in this directory
https://svn.kde.org/home/kde/branches/KDE/3.5/kdelibs/kdoctools/customization/xx
and have a underLGPL.docbook in
https://svn.kde.org/home/kde/branches/KDE/3.5/kdelibs/kdoctools/customization/xx

I am not sure when the entity underLGPL was introduced in kexi's docbook but 
it is not so strange that this entity does not work in translations until it 
is used the first time.

When we want kexi to work under 3.3 we have an impossible problem because we 
can not retroactively add the translated entity underLGPL in all the kdelibs 
out there. This is a generic problem with all programs in extragear and 
koffice which basically means we can never add an entity.

It is not acceptable not to be able to add entities, so the solution is in 
situations like this to expand the entity in branch for that particular 
translated documentation. I am sure this problem will come up many times 
again. It is not really a mess, just a consequence of wanting to rely on old 
verisons of kdelibs in the extragear and koffice modules.

Erik (Danish team0
[prev in list] [next in list] [prev in thread] [next in thread]