Is here the best place to talk about translation of documentation (developer's guide, documentor's guide) or is in the fedora-devel list?
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@lsdr.net
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
Hello Tammy, Paul and all doc writters and translators. First and foremost I wish to say that I'd never participated before of any projects of this kind or even had any role on the RH community whatsoever, but I am very willing to help and its never late to start, so I'll add some cents in this to get the discussion going. Feel free to hammer my feelings if you feel like it, I can bear it as long as its good for the FC.
Tammy Fox wrote:
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:
- CVS location -- separate or in the same module as the original version
The same location has its advantages, but as long as we're talking about diferent trees, so no translator would have write access to a writer's doc and accidentally do some nasty thing. I know the cvs can be "rewinded", but taking vacines is better than antibiotics, isnt it?
Something like / /en_docs (original) /en_docs/burning_cds ... /es_docs /es_docs/grabando_cds ... /pt_br_docs /pt_br_dos/queimando_cds
Etc. or the code for each language. I am not a CVS expert, and my desk is buried in 3 feet of crap, so what you think?
- Method -- there are tools to convert from XML to PO and back to XML -- probably the best choice
Posting these tools on Translations Project on fedora.redhat.com with some, even if small, tutorial/quick guide/tips thingie would be a start, I guess.....
- Process for alert translators of new and changed content
hmm... The docs list? Something that bothers me a lil more than this is actually defining who's onto what. It would be a waste if 2 ppl get the same doc to translate to the same language, without knowing of each others effort. We gotta define something about that.
Well, lets evolve this into a nice organized multi-cultural project! Cheers!!!
Vantroy
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@lsdr.net
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
On Sun, Sep 29, 2002 at 11:29:39PM -0300, Rodrigo Del C. Andrade wrote:
Hello Tammy, Paul and all doc writters and translators. First and foremost I wish to say that I'd never participated before of any projects of this kind or even had any role on the RH community whatsoever, but I am very willing to help and its never late to start, so I'll add some cents in this to get the discussion going. Feel free to hammer my feelings if you feel like it, I can bear it as long as its good for the FC.
Tammy Fox wrote:
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:
- CVS location -- separate or in the same module as the original version
The same location has its advantages, but as long as we're talkingabout diferent trees, so no translator would have write access to a writer's doc and accidentally do some nasty thing. I know the cvs can be "rewinded", but taking vacines is better than antibiotics, isnt it?
Something like
/ /en_docs (original) /en_docs/burning_cds ... /es_docs /es_docs/grabando_cds ... /pt_br_docs /pt_br_dos/queimando_cds
Etc. or the code for each language. I am not a CVS expert, and my desk is buried in 3 feet of crap, so what you think?
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. We also us po files. As files change, the po files in the translation modules are updated so that the translators know to translate the new or changed content. Maybe each writer should be responsible for updating the po files like in software translations. Each translator could monitor the commits to module containing the po files she is responsible for. Of course, we need a CVS server that allows non-RH people to commit first -- we are still working on that.
- Method -- there are tools to convert from XML to PO and back to XML --
probably the best choice
Posting these tools on Translations Project on fedora.redhat.com with some, even if small, tutorial/quick guide/tips thingie would be a start, I guess.....
Sure. Paul and Sarah are the people for this. I just know generally how it works.
- Process for alert translators of new and changed content
hmm... The docs list? Something that bothers me a lil more than this is actually defining who's onto what. It would be a waste if 2 ppl get the same doc to translate to the same language, without knowing of each others effort. We gotta define something about that.
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.
Well, lets evolve this into a nice organized multi-cultural project! Cheers!!!
Vantroy
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@lsdr.net
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
This one came just after I sent my answer...
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.
Let's keep things this way then.
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.
This seems okay to me. I suggest that the person responsable for each translation initiative should be also responsable for marking docs as taken or not in the website.
As for people volunteering for translations, the best way (I think) is to direct them to this list. Here we can tell them how it is done and who they may talk to before starting any translation.
On Sun, Sep 29, 2002 at 11:29:39PM -0300, Rodrigo Del C. Andrade wrote:
Hello Tammy, Paul and all doc writters and translators. First and foremost I wish to say that I'd never participated before of any projects of this kind or even had any role on the RH community whatsoever, but I am very willing to help and its never late to start, so I'll add some cents in this to get the discussion going. Feel free to hammer my feelings if you feel like it, I can bear it as long as its good for the FC.
Tammy Fox wrote:
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:
- CVS location -- separate or in the same module as the original version
The same location has its advantages, but as long as we're talkingabout diferent trees, so no translator would have write access to a writer's doc and accidentally do some nasty thing. I know the cvs can be "rewinded", but taking vacines is better than antibiotics, isnt it?
Something like
/ /en_docs (original) /en_docs/burning_cds ... /es_docs /es_docs/grabando_cds ... /pt_br_docs /pt_br_dos/queimando_cds
Etc. or the code for each language. I am not a CVS expert, and my desk is buried in 3 feet of crap, so what you think?
I was thinking that since we already have the fedora-docs module, we would having fedora-docs-<lang> modules for the translations.
- Method -- there are tools to convert from XML to PO and back to XML --
probably the best choice
Posting these tools on Translations Project on fedora.redhat.com with some, even if small, tutorial/quick guide/tips thingie would be a start, I guess.....
- Process for alert translators of new and changed content
hmm... The docs list? Something that bothers me a lil more than this is actually defining who's onto what. It would be a waste if 2 ppl get the same doc to translate to the same language, without knowing of each others effort. We gotta define something about that.
Well, lets evolve this into a nice organized multi-cultural project! Cheers!!!
Vantroy
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@lsdr.net
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
-- fedora-docs-list mailing list fedora-docs-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-docs-list
- 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?
- 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.
- 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.
On Mon, 2003-09-29 at 21:56, Luiz Rocha wrote:
- 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.
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.
One advantage to this is it helps make public the collaboration process, so we all can learn from and watch out for each other.
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.
Alternately, a project leader with CVS admin control could have module commit messages sent to more granular groups; i.e. the Foo Guide commit messages would be sent to a group list of everyone working on or interested in the Foo Guide; this list of recipients would be maintained through the CVS tools instead of through a mailing list application.
Only other downside that comes to mind -- commit messages might have to be long enough that you won't be able to put it all on one command line. :)
- Karsten
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.
+1 on that, I really liked. I think this will work out right.
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.
Wow, a backup plan! I love community! :)
But I think this won't be necessary. At least for a while. Maybe if we get mass submission of docs, tutorials et cetera, but not for now.
Of course, regular contributors (not only translators) would have to sign it, but I believe it will have a low-to-moderate traffic. And translation collaborators can even not subscribe the fedora-docs-cvs-commits list. The translation leader can alert each one every time their doc gets updated.
"Karsten" == Karsten Wade kwade@redhat.com writes:
... Karsten> Have the fedora-docs-list receive the CVS commit notice, which Karsten> would include log messages and the {unified,context} diff. The Karsten> commit message could then contain information for the translators Karsten> and other writers working on the module. ...
I use this for the Red Hat Enterprise Linux release notes, and it is very handle to see who else is doing things to the module...
... Karsten> If this ends up being too much noise on the list, we could have a Karsten> separate fedora-docs-cvs-commits list for just those who need to Karsten> actively watch. Collaborators can remain subscribed but choose to Karsten> disable delivery until they know there are more changes coming.
This sounds best -- the commit messages can quickly become overwhelming...
... Karsten> Only other downside that comes to mind -- commit messages might Karsten> have to be long enough that you won't be able to put it all on one Karsten> command line. :) ...
The script that we use to send the messages (can't remember the name ATM) has a fair bit of flexibility; we should be able to cut it down to something reasonable... :-)
Truth be told, for this kind of situation, I wonder if the commits-list really needs full diffs, or could just get by with a message containing a well-written, informative log message (hint, hint)... ;-)
That way, people interested in that particular document would know something has changed, and could update their working copy to get the details...
Ed
On Tue, Sep 30, 2003 at 01:56:47AM -0300, Luiz Rocha wrote:
- 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?
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.
- 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?
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.
I mean, this may be functional for short, interface translations, but for long, descritive documents, I don't know.
Our RHEL docs are very long, and it works for them.
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.
- 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.
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.
Tammy
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@lsdr.net
-- fedora-docs-list mailing list fedora-docs-list@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?
On Tue, Sep 30, 2003 at 11:53:54PM -0300, Luiz Rocha wrote:
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.
Exactly.
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?
QA is always a good thing. We will probably just have to see how many translators we have. If we have enough for this process, then I am all for it.
Tammy
-- Luiz Rocha lsdr@lsdr.net
-- fedora-docs-list mailing list fedora-docs-list@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.
On Wed, Oct 01, 2003 at 10:46:12PM +0200, Göran Uddeborg wrote:
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.
The RH translators use KBabel. I have asked them to join the list and give us details.
Tammy
- 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.
On Thu, Oct 02, 2003 at 02:28:10AM -0300, Luiz Rocha wrote:
- 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@lsdr.net
I think the internal RH translators use po2xml, xml2pot, and msguniq.
I have asked them to join this discussion, but they are really busy right now so maybe they don't have time.
Tammy
I think the internal RH translators use po2xml, xml2pot, and msguniq.
Thanks, Tammy.
Göran Uddeborg writes:
- 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.
Sorry, not the first two, the first and third (po-mode and KBabel).
docs@lists.stg.fedoraproject.org
-
Edward C. Bailey -
Göran Uddeborg -
Karsten Wade -
Luiz Rocha -
Rodrigo Del C. Andrade -
Tammy Fox