This would be the place. We currently don't have a process for it, but I would love to hear your ideas for it such as: 1. CVS location -- separate or in the same module as the original version

2. Method -- there are tools to convert from XML to PO and back to XML -- probably the best choice

3. Process for alert translators of new and changed content

Cheers, Tammy On Mon, Sep 29, 2003 at 01:59:13AM -0300, Luiz Rocha wrote: > Is here the best place to talk about translation of documentation >(developer's guide, documentor's guide) or is in the fedora-devel list? >-- >Luiz Rocha <lsdr(a)lsdr.net&gt; > > >-- >fedora-docs-list mailing list &gt;fedora-docs-list(a)redhat.com >http://www.redhat.com/mailman/listinfo/fedora-docs-list -- fedora-docs-list mailing list fedora-docs-list(a)redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list

For the RHEL docs, for each English module, there is a corresponding module for each language the English module is translated into. It works out well.

Yes. We need a way for people to volunteer for translations and a way to clearly mark that doc as taken. Other projects do this with a website that shows the progress and the owner.

1. CVS location -- separate or in the same module as the original version

2. Method -- there are tools to convert from XML to PO and back to XML -- probably the best choice

3. Process for alert translators of new and changed content

Here's the starting point of an idea, which might get out of hand. :-P Have the fedora-docs-list receive the CVS commit notice, which would include log messages and the {unified,context} diff. The commit message could then contain information for the translators and other writers working on the module.

If this ends up being too much noise on the list, we could have a separate fedora-docs-cvs-commits list for just those who need to actively watch. Collaborators can remain subscribed but choose to disable delivery until they know there are more changes coming.

> 1. CVS location -- separate or in the same module as the original version I think both would work. Is an organization matter. Once we get any of the going, will be fine. I checked out the fedora-docs tree and I think that something like common/ css/ en/ fr/ pt-br/ xsl/ would be okay. But this is my opinion only. How exactly this is done in RH?

> 2. Method -- there are tools to convert from XML to PO and back to XML -- > probably the best choice Is the XML to PO back to XML dance really necessary?

I mean, this may be functional for short, interface translations, but for long, descritive documents, I don't know.

Personaly, I rather have a CVS diff with the changes in a document and grok the XML directly. I like having the full doc I'm translating in front of me. But that's just me, I could do the XML/PO dance, no problem. I will look for some tools to do it. > 3. Process for alert translators of new and changed content I think the best way is to always post in the fedora-docs list any changes made in any document. Translators them should update the translated versions. Each translation initiative should have someone responsable for it.

In the apache-docs list, they had someone mailing every week a status of the project, listing which docs required revision/enhancements e etc... We could do something like that, including files that need translation and translations that require revision/update. -- Luiz Rocha <lsdr(a)lsdr.net&gt; -- fedora-docs-list mailing list fedora-docs-list(a)redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list

> Separate modules per language is better so everyone doesn't have to > check out all the languages. The bigger the docs get, the more > diskspace this is going to take. Something like fedora-docs and fedora-docs-pt_BR then ? (I saw your other post...) I think it is okay. Could we keep only PO files in the fedora-docs-<lang> modules? I mean, to avoid having duplicated stylesheets and css and all in different modules. There is another advantage. If head translators gain -maybe, in the future- CVS commit access, they would only work inside their language module, which would avoid some trouble.

> No. It is not necessary, but our internal RH translators have > translated using both methods and feel that using PO files is a > superior method. XML to PO to XML has some advantages such as not > marking computeroutputs as text to be translated since it is direct > output from a configuration file or source code. Another advantage is > that it marks content as fuzzy, which helps if someone just changes a > few words in the master verson. I'm sure Paul or Sarah could expand on > the benefits. Yes, well, I was looking some PO files today and doing some thinking, and I guess the XML to PO to XML would be actually better. > Our RHEL docs are very long, and it works for them. It should work for us too. Is just that I like XML and never worked with PO files, so rejection was a natural instinct. And as Rodrigo pointed out, would be nice to post here or in the website which tools you guys use for this, so we could use the same ones. > I like Karsten's suggestions of having commit messages go to this list > and maybe a different list if the traffic gets annoying. Ed's idea to > not show the diff is a good one as well. If we use a different CVS > server than the current one we are using, we could change the syncmail > script. If we share with devel, I don't think they are going to want > that. Of course, I can also setup a separate CVSROOT for us on the > same server and use a different syncmail. I like'em both too. I like to see diffs, but a nice log would suffice while keep the traffic under control. Oh, and there is another thing I'd like to ask you and the others. In the apache-docs project, they ask for every translation to have a revision by another fluent (or native) speaker of the given language. While this avoids mistakes and increases the quality of the docs, it tends to slow down the translation process. I think it would be nice to ask for revisions but not make it mandatory. What do you guys think about it?

-- Luiz Rocha <lsdr(a)lsdr.net&gt; -- fedora-docs-list mailing list fedora-docs-list(a)redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list

Luiz Rocha writes: > And as Rodrigo pointed out, would be nice to post here or in the website > which tools you guys use for this, so we could use the same ones. On the web page for the Swedish translation team I enumerate these suggestions: - Emacs' po-mode. - gtranslator <http://www.gtranslator.org> - KBabel <http://i18n.kde.org/tools/kbabel/> - poEdit <http://poedit.sourceforge.net/> The first to comes with the distribution. The one I use personally is po-mode in emacs, and I can recommend it. Works fine except for plural forms. If you are not an emacs user, you might wish to look at the others, though.

> > - Emacs' po-mode. > > - gtranslator <http://www.gtranslator.org> > > - KBabel <http://i18n.kde.org/tools/kbabel/> > > - poEdit <http://poedit.sourceforge.net/> I have KBabel installed in my machine. I'll that a look on the other tools as well. > The RH translators use KBabel. I have asked them to join the list and > give us details. Then I'll play with KBabel first. Another question (from a gettext ignorant). Which tools, if any, you guys use to generate the PO files? I downloaded the gettext manual, but I want to be practical. -- Luiz Rocha <lsdr(a)lsdr.net&gt;

- Emacs' po-mode. - gtranslator <http://www.gtranslator.org> - KBabel <http://i18n.kde.org/tools/kbabel/> - poEdit <http://poedit.sourceforge.net/> The first to comes with the distribution.