Our documentation building process requires an additional file "rpm-info.xml" that contains metadata about the document, such as revision history, title, authors, etc. The way things stand now, translators should edit this file directly, adding translations like:
<translation lang="en"> <title>Example Tutorial</title> <desc>How we do it</desc> </translation> <translation lang="de"> <title>Beispieltutorial</title> <desc>Data data data...</desc> </translation>
I am just now learning how translation works, thanks to Manuel Ospina's Translation Quick Start Guide. Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
I am just now learning how translation works, thanks to Manuel Ospina's Translation Quick Start Guide. Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
What about this would be easier? We would then need another DTD to avoid requiring information duplication, or one "rpm-info.xml" would need to be primary.
The actual non-English information in the current "rpm-info.xml" seems quite minimal in contrast with translating an entire document.
However, I could be convinced.
Debate welcomed.
On Fri, 2006-01-27 at 12:59 -0600, Tommy Reynolds wrote:
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
I am just now learning how translation works, thanks to Manuel Ospina's Translation Quick Start Guide. Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
What about this would be easier? We would then need another DTD to avoid requiring information duplication, or one "rpm-info.xml" would need to be primary.
We wouldn't need any additional DTD; see the Translation Quick Start Guide for info on how translators work. They simply do an xml2po or xml2pot, and translate the appropriate element content.
The actual non-English information in the current "rpm-info.xml" seems quite minimal in contrast with translating an entire document.
However, I could be convinced.
Debate welcomed.
The translators' existing (and efficient, AFAICT) process doesn't jibe well with what we require of them in rpm-info.xml. I really don't care one way or the other, personally; I am just trying to make translation easy for those who are devoting their volunteer time to it. If some of them are finding it confusing -- which I think may be the case, given how few of them are adding the appropriate translation information to the rpm-info.xml currently -- then it makes sense for us to fix our process, rather than requiring them to adjust purely for FDP usage.
On the other hand, it is minimal content for now. If Manuel and others agree, we could just fix the TQSG to reference how specifically the rpm-info.xml needs to be updated by translators. Right now, that procedure doesn't seem to follow the "simple + elegant" method, which describes the normal translation process IMHO.
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
I am just now learning how translation works, thanks to Manuel Ospina's Translation Quick Start Guide. Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
The actual non-English information in the current "rpm-info.xml" seems quite minimal in contrast with translating an entire document.
The translators' existing (and efficient, AFAICT) process doesn't jibe well with what we require of them in rpm-info.xml.
Sorry, I hadn't made that connection. Good catch.
By all means, let's use a technique that works well all on its own. Seamless, and all that.
Still, we need a way of thinking about the "rpm-info.xml" file that matches the plethora of "rpm-info-${LANG}.xml" files. Workers, titles and descriptions I can see being "translated" well enough.
Will there be an authoritative changelog? If so, where? Keeping it in the English translation seems, well, chauvinistic. Per-language changelogs? Hmm. Appealing.
Perhaps we haven't done a good job highlighting that the "rpm-info.xml" file is really a multi-lingual document, instead of being English-only. Name change in order?
I'm willing to bow to experience here; I'm limited to translating between English and Good Ole' Boy English.
Cheers
Il giorno ven, 27/01/2006 alle 10.16 -0800, Paul W. Frields ha scritto:
Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
I think it would be more intuitive... than check for comments or tags in the xml file...
Best regards
On Sat, 2006-01-28 at 02:10 -0500, Francesco Tombolini wrote:
Il giorno ven, 27/01/2006 alle 10.16 -0800, Paul W. Frields ha scritto:
Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
I think it would be more intuitive... than check for comments or tags in the xml file...
I am having some second thoughts about this. The lure of i18n'ing this file just like all others is very strong, but there are some significant problems it creates which weren't apparent to me at first blush. For example, RPM changelogs also come out of this file for our packaging process. Those are normally not translated. This would mean the confusion created by requiring translators *not* to translate certain parts of the new rpm-info-*.xml files would be roughly equal to the situation we had before. Worse, though, it represents a possibility of mismatch in the RPMs, or at least the appearance of mismatch when translations are out of sync with the English versions at packaging time.
More discussion is welcome, with an eye toward rolling some docs out the door into Fedora Extras at or near FC5t3 release. Tommy normally catches me when I think up Bad Ideas, so I could be wrong in thinking we need to change course.
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
I think it would be more intuitive... than check for comments or tags in the xml file...
I am having some second thoughts about this.
Tommy normally catches me when I think up Bad Ideas, so I could be wrong in thinking we need to change course.
Busted, again ;-)
I would vastly prefer to use a single rpm-info.xml file and have all portions of that be authoritative. Otherwise you are faced with having some rpm-info files be more equal than others, on a stanza-by-stanza basis. Notice in the fdpsh and Makefile.common changes I've just checked in there must be the notion of a "primary language" for a document: the locale of the original, authoritative rpm-info-${LANG}.xml file. After all, not all documents will originate in "en", will they? The complications and accommodations seem to be creeping in. Let's stomp them out.
My original vision was that a single rpm-info.xml file would contain ALL the meta-information for a document. There didn't seem to be a way to have a separate ".spec" file for each language (and thus separate RPM's) and that implied that all the changelog activity could be lumped together.
BTW, I considered the "%changelog" to not strictly be an RPM or document ChangeLog as such, but to represent more of an event log. Each correction, addition, or packaging event would be recorded there. Just before an RPM package release, a new RPM event would be added thus marking the RPM version and release. No need to synchronize the document versions with the RPM versions unless convention dictated.
Not a course change, just a return to sanity.
You have now read my $0.02USD. What is yours? We await your pleasure.
On Sat, 2006-02-04 at 18:37 -0600, Tommy Reynolds wrote:
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
Would it be easier for translators if we moved to using "rpm-info-en.xml", "rpm-info-de.xml", etc.? Comments welcome.
I think it would be more intuitive... than check for comments or tags in the xml file...
I am having some second thoughts about this.
Tommy normally catches me when I think up Bad Ideas, so I could be wrong in thinking we need to change course.
Busted, again ;-)
I would vastly prefer to use a single rpm-info.xml file and have all portions of that be authoritative. Otherwise you are faced with having some rpm-info files be more equal than others, on a stanza-by-stanza basis.
This is far more clear than the way I stated my new misgivings. Thanks.
Notice in the fdpsh and Makefile.common changes I've just checked in there must be the notion of a "primary language" for a document: the locale of the original, authoritative rpm-info-${LANG}.xml file. After all, not all documents will originate in "en", will they? The complications and accommodations seem to be creeping in. Let's stomp them out.
Agreed. One question: why not have an authoritative "rpm-info.xml" file just live in the doc module root? That seems even more intuitive, so translators need not hunt through the other modules or read Makefile stuff to figure out where the rpm-info lives for a specific doc, in the even that it's not "en". Plus it gives the correct impression that it is the One XML that rules over an entire set of translations. Or am I going insane again?
My original vision was that a single rpm-info.xml file would contain ALL the meta-information for a document. There didn't seem to be a way to have a separate ".spec" file for each language (and thus separate RPM's) and that implied that all the changelog activity could be lumped together.
Yes, although it would be possible to do separate "<doc>-*.spec" files (with separate "rpm-info-*.xml" files), it would be clumsy, a maintenance nightmare, and ill-advised. Far better to wait for documents to achieve uniformity through complete translations, and only then roll the packages.
BTW, I considered the "%changelog" to not strictly be an RPM or document ChangeLog as such, but to represent more of an event log. Each correction, addition, or packaging event would be recorded there. Just before an RPM package release, a new RPM event would be added thus marking the RPM version and release. No need to synchronize the document versions with the RPM versions unless convention dictated.
Right, it would be more of the nature of "We've made some good fixes, they've all been translated into the target languages, time to ship an RPM update."
Not a course change, just a return to sanity.
You have now read my $0.02USD. What is yours? We await your pleasure.
Yes, if some additional translators (I already heard from one) would confirm that this doesn't burden them -- remembering to put translations in certain elements of the "rpm-info.xml" file -- that would be grand. I will put a little bit of comment fluff in the XSL stylesheets to indicate clearly what to translate.
Is there any standardized way for indicating parts of an XML file that should not be translated? Some sort of outboard configuration that is understood by xml2po{,t}?
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
Notice in the fdpsh and Makefile.common changes I've just checked in there must be the notion of a "primary language" for a document: the locale of the original, authoritative rpm-info-${LANG}.xml file. After all, not all documents will originate in "en", will they? The complications and accommodations seem to be creeping in. Let's stomp them out.
Agreed. One question: why not have an authoritative "rpm-info.xml" file just live in the doc module root?
Yes, having a single authoritative "rpm-info.xml" file in the document root is the one true way(tm).
Yes, if some additional translators (I already heard from one) would confirm that this doesn't burden them -- remembering to put translations in certain elements of the "rpm-info.xml" file -- that would be grand.
Well, that's one more than I've heard from. Could this really be a non-issue in the grand scheme of things?
I will put a little bit of comment fluff in the XSL stylesheets to indicate clearly what to translate. Is there any standardized way for indicating parts of an XML file that should not be translated? Some sort of outboard configuration that is understood by xml2po{,t}?
Dunno, but don't think so.
However, I took some care in selecting which XML elements included a "lang=foo" attribute. Is that a sufficient hint?
Cheers
-
Francesco Tombolini -
Paul W. Frields -
Tommy Reynolds