Re: Idea: each FAQ as its own xml file
Michèle Garoche <[email protected]>
| Newsgroups | gmane.os.apple.fink.i18n |
|---|---|
| Message-ID | <[email protected]> |
Le 17 août 2004, à 16:29, BABA Yoshihiko a écrit : > Hi, > > On 2004/08/17, at 9:54, Michèle Garoche wrote: > >> >> Le 17 août 2004, à 2:42, Daniel Macks a écrit : >> >>> On Tue, Aug 17, 2004 at 02:33:02AM +0200, Mich?le Garoche wrote: >>>> Le 17 ao?t 2004, ? 2:18, Daniel Macks a ?crit : >>>> >>>>> I just looked at our translations of the Fink FAQ, and it looks >>>>> like >>>>> some languages have fallen behind. In trying to sort it all out, I >>>>> became frustrated with the current source (.xml) file layout: each >>>>> FAQ >>>>> entry is really a self-contained item that may be changed (or >>>>> added or >>>>> removed), but we only have a single source file for the whole >>>>> FAQ. Would it be better to have each as a separate file (which the >>>>> build system joins together)? That way when committing a change, >>>>> it is >>>>> clear which FAQ item was updated and one could note that "this >>>>> corresponds to english rev 1.38" to make it easy to keep things in >>>>> sync. This cannot be done now, because a single new revision could >>>>> involve many changed FAQs. It might be easy for some to be >>>>> translated >>>>> quickly, but not others, but keeping track of corresponding >>>>> revision >>>>> numbers requires knowing that they are all done. >>>> >>>> And how do you deal with faq referring to another faq, when one of >>>> them >>>> is removed or renamed or merged if you split the faq in chunks? >>> >>> Same way we do now: by <chapter> and <faqentry> "name=" attribute. >>> >>>> The problem is not faq, the problem is to find people who can spend >>>> as >>>> many time as it is required within a short delay to translate the >>>> whole >>>> thing (not only faq). >>> >>> Exactly. That's I proposed this...to make it easier to see what needs >>> to be done, and make the task seem less intimidating (small units, >>> instead of a giant file). It seems easier to organize "this-language >>> now corresponds to the current that-language" than to keep track of >>> which "[translate] ..." emails have been dealt with. >> For me, it makes the things a lot more complicated, so much files to >> deal with, and it is not so complicated to translate by chunks as I >> did. This way you know exactly what you do. >> >> I just say, if I may say something, I'm completely against it. > > I understand the complexity. But, that doesn't solve the problem: > FAQ's in other languages don't match the English FAQ. As far as I know, French FAQ matches the English one, unless I've missed something, which is not to be excluded of course. If others do not match the English FAQ, that is probably due to the lack of cvs updating systematically the tree before starting to translate one small chunk and before commiting this same small chunk, to be sure to catch the latest FAQ and also to the lack of forwarding systematically the cvs commit to the mailing list, and to update immediately the part which has already been translated and has changed in the English FAQ. It's already difficult not to have discrepancies between the English files themselves, I mean a search on all the files are not made systematically when someone changes the name of an item, it's place (for the FAQ) or simply disables/removes it, which leads to broken links if any. I don't see how a multiplication of the files would make the things better. If the translator should have to make the check in place of the documentarian, it would be even worse. Finally, the mailing list is so still that I doubt translators really read it. For what it's worth, I use gmame to read the commits. Michèle <http://micmacfr.homeunix.org>
PGP.sig
(application/pgp-signature, 186 B) - not displayed