Re: Idea: each FAQ as its own xml file

(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. 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.

So, onward. Baba's thought of having each language default to the
English if the native translation isn't available is interesting. 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.

Consider: each FAQ is a (mostly) self-contained entity. 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. 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. 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.

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.

dan

-- 
Daniel Macks
[email protected]
http://www.netspace.org/~dmacks



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285