From kde-i18n-doc Tue Jun 21 07:09:29 2005 From: Lauri Watts Date: Tue, 21 Jun 2005 07:09:29 +0000 To: kde-i18n-doc Subject: Re: Generating docs for kdeextragear Message-Id: <200506210909.33772.lauri () kde ! org> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=111933784315601 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1190413.0euvpm8h5m" --nextPart1190413.0euvpm8h5m Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 21 June 2005 08.26, Krzysztof Lichota wrote: > Nicolas Goutte 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= =20 html, which is what is in the index.cache.bz2. This is what khelpcenter=20 displays. KHelpcenter *can* do the conversion, but it's slow and it's a=20 last resort, only if the index.cache.bz2 is not present or not usable, or=20 there have been changes requiring an update. Step 3 is a fallback, if you are seeing khelpcenter regenerate docs every=20 single time, then there is something going wrong. > > Entities are needed in step 2 and 3. I would like to move expanding them > into step 1, so that they are not necessary later. It's really not that easy. =20 > > - write again author names, emails etc in full instead of using an enti= ty > > for such critical docs. (However this is also again going back to the o= ld > > 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 po= int=20 you could expand the entities is during po -> xml conversion. And you only= =20 need write out the *new* entities, the ones that have been added since=20 whatever version of kdelibs the hypothetical author is supporting. > > - 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 docume= nt=20 (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=20 regexp and awk probably can.) It's a very simple problem, the issue here i= s=20 as much social as technical - we still have to know that it needs fixing,=20 before it can be. Expansion of entities not available in older kdelibs is = a=20 special case, the normal case does not require it at all. Regards, =2D-=20 Lauri Watts KDE Documentation: http://docs.kde.org KDE on FreeBSD: http://freebsd.kde.org --nextPart1190413.0euvpm8h5m Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCt70t/gUyA7PWnacRAmEoAJ4kUKIufcckXUoFjDuKJlsWWH9VSACfeT0o tWB9A5NP2bjPaA1Qjf+dhko= =Xf0f -----END PGP SIGNATURE----- --nextPart1190413.0euvpm8h5m--