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

List:       kde-i18n-doc
Subject:    Re: Generating docs for kdeextragear
From:       Krzysztof Lichota <krzysiek () lichota ! net>
Date:       2005-06-26 1:44:21
Message-ID: 42BE0875.2070401 () lichota ! net
[Download RAW message or body]

Lauri Watts wrote:
>>>On Tuesday 21 June 2005 00:17, Krzysztof Lichota wrote:
> 
>>Step 2 (compiling) - translated docbook is compiled using meinproc into
>>index.cache.bz2 and docbooks/images/index.cache is installed in system.
>>This step is done by user, who compiles and installs application in the
>>system.
>>Step 3 (displaying) - khelpcenter transforms docbooks using XSLT into
>>HTML and displays them.
> 
> Not quite.
> 
> Step 2, during compile, the docbook is converted *by meinproc* with xslt to 
> html, which is what is in the index.cache.bz2.  This is what khelpcenter 
> displays.   KHelpcenter *can* do the conversion, but it's slow and it's a 
> last resort, only if the index.cache.bz2 is not present or not usable, or 
> there have been changes requiring an update.
> 
> Step 3 is a fallback, if you are seeing khelpcenter regenerate docs every 
> single time, then there is something going wrong.

No, I just thought it was doing so.

>>>- write again author names, emails etc in full instead of using an entity
>>>for such critical docs. (However this is also again going back to the old
>>>KDE behaviour.)
>>
>>This is rather radical. I would prefer to have entites expanded
>>automatically during generation of docbooks, as I described above.
> 
> Except, there is no generation of the docbook, as I explained.  The only point 
> you could expand the entities is during po -> xml conversion.  And you only 
> need write out the *new* entities, the ones that have been added since 
> whatever version of kdelibs the hypothetical author is supporting.

Yes, I think it should be done during po->xml conversion. But I don't 
understand why it should be done only for new entities? I think it 
should be done for all "user" entities.

>>>- the translation should have the possibility to
>>>manipulate the !DOCTYPE, so that translators can add entities there. (As
>>>far as I know, this is not possible currently.)
> 
> 
> This is a much better solution.
> 
> 
>>But it means we would have to add all possible entites to headers of all
>>translated docbooks? It would be a lot of work to keep it consistent
>>everywhere. I think this was the reason why common entities were
>>introduced.
> 
> 
> No, it would mean you *could* include entities that are local to the document 
> (and those that are for the purpose of supporting older kdelibs)
> 
> More to the point, a useful text editor can expand the entities (heck, a 
> regexp and awk probably can.)  It's a very simple problem, the issue here is 
> as much social as technical - we still have to know that it needs fixing, 
> before it can be.  Expansion of entities not available in older kdelibs is a 
> special case, the normal case does not require it at all.

It depends what "older" kdelibs mean. For example for Polish team, as we 
are only beginning translation of docs, "user" entities are changed 
quite often. And in order to generate new translated docs one would have 
to update kdelibs. And this sucks.

Regards

	Krzysztof Lichota (Polish team)

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