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

List:       kde-i18n-doc
Subject:    Re: [RFC] short message "unfreeze" before KDE 3.5.1
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-12-03 13:28:31
Message-ID: 200512031428.31818.nicolasg () snafu ! de
[Download RAW message or body]

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 <sarcasm>volunteers</sarcasm> 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!


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