From: Daniel M. <dm...@ne...> - 2004-08-19 02:17:52
|
(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 dm...@ne... http://www.netspace.org/~dmacks |