Re: Idea: each FAQ as its own xml file

Le 19 août 2004, à 4:17, Daniel Macks a écrit :

> (Sorry I haven't had a chance to respond to the past day's messages)
>
> First, it is not my goal to force this (or any) new system on the doc
> team. However, there's no denying that some translations appear to
> have stagnated. Whether that's because nobody is volunteering to do
> the work or nobody is coordinating the effort, I don't know.
Both certainly. And here we can make a change.

>  But I do
> know that the current system seems (to me) complicated and overly
> administrative. If the problem is lack of coordination, then changing
> to a system that requires less coordination seems smart. If the
> problem is lack of volunteer translator time, then switching to a
> system that keeps the ongoing work as easily-identified bite-sized
> chunks seems smart. That's why I proposed what I did. I'm happy to
> work on this, but really, it's up to the doc team to figure out what
> (if any) changes to make.
Problem is where is the doc team? We are alone (baba, you and me) to 
discuss this here. That's where things are not satisfactory.

> So, onward. Baba's thought of having each language default to the
> English if the native translation isn't available is interesting.
I think this is the better thing to do, because finally that the result 
which is wanted. I simply say I don't see how you can do that in such a 
way that you are sure you don't put additional burden on the translator 
or the documentarian.

>  I
> wasn't even thinking of something that drastic, though...just put each
> FAQ in its own file and then have Makefile string them all together
> with a simple skeleton to get back to what we have now.
That for me is additional burden on translator or documentarian.

>
> Consider: each FAQ is a (mostly) self-contained entity.
That's the mostly which is the problem here.

>  In a given
> non-.en language, it could {not exist, be outdated, be up-to-date,
> exist but be deleted in .en}, and this is fairly independent of the
> state of any other FAQ entry.
Not always independent, especially in the case of deletion.

>  By tagging (CVS commit message) each
> with what .en version it corresponds to, it removes the need to keep
> any sort of master record of what changes to "the FAQ" still need to
> be translated: just compare the .ja commit msg to the .en HEAD
> revision number.
But that you can do it right now. No need to split the files.

Observe what happens if a change is made in English file because of 
misspelling. Will you tag the other language files with outdated? This 
is fully wrong here.

>  It also makes it easier for a team to translate "a
> part at a time" and require less coordination (both manpower and CVS):
> there's no need to have to re-integrate a translator's changes for one
> FAQ into a huge .zh that may haev changed in other places in the mean
> time.
I don't agree here. It's fare more easier to translate a part of a huge 
file and integrate new changes than to keep traces of a huge numbers of 
files and know at any time which one needs translation or which one is 
up to date.

I mean the less files you have, the easier is the job.

> Our build system is already quite complicated and a bit fragile, and
> there are certainly modifications that could be made, and even whole
> other ways of doing things (with both pros and cons, and attendant
> migration issues and learning curve). But if people are happy with the
> current system, that's fine too.
No, I don't say I'm happy with the current system, though it is not 
that bad. But I really would like to hear some other translators here. 
I feel like the bad girl who always contradicts.

Michèle
<http://micmacfr.homeunix.org>