From kde-i18n-doc Sat Dec 03 13:28:31 2005 From: Nicolas Goutte Date: Sat, 03 Dec 2005 13:28:31 +0000 To: kde-i18n-doc Subject: Re: [RFC] short message "unfreeze" before KDE 3.5.1 Message-Id: <200512031428.31818.nicolasg () snafu ! de> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=113361660425265 On Friday 02 December 2005 23:35, Burkhard Lück wrote: > Am Freitag 02 Dezember 2005 11:00 schrieb Nicolas Goutte: > > It is much less a problem to "allow" than a technical problem how to make > > it work. > > > > We have currently the tool chain that we have: > > - POT files are created from the DocBook > > - Scripty merges the POT files to corresponding the corresponding PO > > files - original DocBook and translated PO files are merge in the > > translated documentation. > > I see no technical problem, just allow to update the documentation for > stable all the time and run the script to generate/merge the docpo files, > this only effects the translation stats Problem number one. Perhaps not the biggest one, but there seem to be many people wanting right statistics (at least they want them for GUI, so I suppose that they want it for docs too). > and the doc po files, but neither > already generated language docbooks And what if you want to generate new DocBooks? You have only the choice to generate them with the current PO files, which have been merged with the current POT files. Too bad if the POT files were just changed for a new fix. > nor compile/install of an already > translated language. > > If a team generates again the language docbooks with update_xml, it never > looses a previously succesfully generated language docbook, But the problem is not only to keep the old work. You must be able to do the current one too in correct conditions. And especially the language coordinator must be able to do this. > even if the > current corresponding docpo file has fuzzies or untranslated messages, > because update_xml does not process docpo files with fuzzies or > untranslated messages. So as written above, a new fix in the untranslated DocBook and you can start again your work... > > Nobody can loose, Sorry, I do not see it so. And problems like "What has happened to my Amarok docs?" will happen even more. And with even less chance to understand what has happened, as the SVN repository would not be authoritative anymore. > but everybody can win: > The doc team has uptodate documentations in stable, the languages teams > always translate the latest documentations in stable. I do not mind to have a new clean solution. But I would like a stable new solution, not one that can lead to total chaos. (Because in case of total chaos, I know already who are the volunteers to fix it again.) > > > Currently, the tools for DocBook to POT and POT to DocBook are compiled; > > that seems to be a problem too for many teams. > > compiled? update_xml is just a bash script. The update_xml Bash script is mainly an envelope. What is making the real work is po2xml which is a compiled program from kdesdk/poxml Also the script uses meinproc. (That is a point that I had missed to consider.) > -v please Good, in --verbose mode: the easiest way I would see would be to tell the translators: "here are the DocBook documents, here are the tools, here are where you have to put the translated DocBook documents; please make the work!" However when I see that even something simple like msgmerge is never done by hand, how can such a big procedure to call xml2pot, msgmerge, po2xml is expected to be done manually? (I would be very happy to disable the msgmerge for docmessage, it would let Scripty gain probably many hours.) Sure it would immensilely help if tools like KBabel would have a mode where you put the untranslated DocBook in and get the the translated DocBook out. While this is a wish for KBabel, it will still need years before it is implemented (at the current available rate of developers availbale for KBabel and the hugeness of the other tasks). > > Burkhard Lück Have a nice day!