We may move this up, at least in terms of getting it all working in your sandbox. We are looking to connect into the i18n.redhat.com tools for FC5, meaning that we can get the relnotes translated across many possible languages between test3 and FC5. If we move fast enough, it's possible we could do this for test3. For $REASONS_UNSPEAKABLE, I think we may have, oh, say an extra five days to accomplish this, starting now. release-notes/en/RELEASE-NOTES-en.xml ... Is this the idea? Or ... I'm blocking the FC5 relnotes tracker with this one, we want to do it. Carry on!
Are we considered ready to go for i18n.redhat.com yet? What is remaining?
Translation Project leaders: We think the release notes are ready to hook into i18n.redhat.com. You want to post the .po files for translation no later than 27 Feb. We will have new content at that time, generated from the Wiki. You may want to post the existing .po files. Only a % of the content is going to change between now and then, this would give translators an early start. Do you need anything more from us? Our schedule is here: http://fedoraproject.org/wiki/DocsProject/Schedule
I think we have a snag that we'll have to solve on 28 Feb. The translator leadership hasn't been able to get any .pot files because of a missing xml2po application, iirc. Also, I don't know if i18n.redhat.com is available for this release, or are we doing this with the translators who have cvs.fedora accounts?
For the record, xml2po(1) is part of the "gnome-doc-utils" package. Is there a problem obtaining this package? It is part of the "Development/Tools" group in Anaconda & system-config-packages.
Also note that this package doesn't have any dependencies on the sizable GNOME libraries -- only python, libxml2 and libxslt, all of which I would expect users have installed, so "yum install gnome-doc-utils" won't drag in a ton of extra baggage.
Perhaps the issue is that some of our I18N workers are on that other operating system; you know, the one you need CYGWIN to retain your sanity ;-) I've now taken the position that it is good, nay, required, practice to include the .POT file as part of the CVS archive. Although, it's a generated file, not everyone who needs to work with it can do the generating. Everybody can handle the .POT and .PO files with native tools, so I'll make a policy exception here.
Sounds cool to me. We do have a policy of not providing tools that support non-Fedora Core systems, but this is not a tool as much as a practice to adopt. When do we need to regenerate a .POT file? a. For every commit? b. For every milestone that gets a CVS tag? I have a feeling we are getting close to having a 'make cvs-commit' or some fdpsh function. :)
The .POT file will be automatically regenerated every time the ${XMLFILES-${PRI_LANG} XML files are changed and *any* higher-level targets (like make xml-${PRI_LANG} or make html-${PRI_LANG}) get executed. There is also a standalone "make pot" target. My recommendation is to test the XML files by a "make html-${LANG}" test and then CVS commit everything, just as we currently do. Make sure that the .POT file has been introduced to CVS, though.
Thanks for all the hard work on this, we're done for now, right? Closing and all that.
Ticket moved to allow products to be removed from BZ.