[opensuse-translation] proposal for organizing translation work
I was talking with Elliot Murphy from Canonical regarding Launchpad (launchpad.net). For those who doesn't know Launchpad, it's a web tool to organize collaboration. Also is the Ubuntu development site (they host their source, translations, bugs, etc). The translation tool seems very interesting, it is possible to use the online tool (and have access to a 800k+ string database) or download the po file for local work. Also you can have a track of what file is being translated and by who, and more. One of the main thing I asked him was about svn support. He's reply was that Launchpad has native support to a version control tool called Bazaar, and it's possible to do continuous import from a svn repository. Maybe we can get some ideas from there, or even use it. -- Kind Regards Visitá/Go to >> http://www.opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gabriel . wrote:
I was talking with Elliot Murphy from Canonical regarding Launchpad (launchpad.net). For those who doesn't know Launchpad, it's a web tool to organize collaboration. Also is the Ubuntu development site (they host their source, translations, bugs, etc).
The translation tool seems very interesting, it is possible to use the online tool (and have access to a 800k+ string database) or download the po file for local work. Also you can have a track of what file is being translated and by who, and more.
One of the main thing I asked him was about svn support. He's reply was that Launchpad has native support to a version control tool called Bazaar, and it's possible to do continuous import from a svn repository.
Maybe we can get some ideas from there, or even use it.
It's most probably a very nice tool, but using it is a big "no way" because it isn't opensource nor free. The really interesting technical aspects aren't so much about VC integration (which is something a tool like that must have anyway, if it doesn't it's useless), but rather how it is organized and merged with upstream. That's one of the biggest technical issues because if it's translated just for Ubuntu (or openSUSE or Fedora or ...) and doesn't get merged by upstream, then it's not an option. And as a long time packager, believe me, working with upstream is a very, very difficult thing to solve because there are no tools nor standards (in terms of tooling -- for data representation there's GNU gettext (po) and TMX (http://www.lisa.org/standards/tmx/)) nor centralized way to communicate additions/patches, etc... But yeah, indeed, it would be great to have a tool that is both easy to use and potent enough to merge with upstream, because translation is an obvious topic where lots of people can contribute, even people who have less experience in the technical field (note that I said "less experience", not "no experience" ;)). http://lxer.com/module/newswire/ext_link.php?rid=94625 https://hosted.fedoraproject.org/projects/transifex/ http://pootle.wordforge.org/ cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHWdBzr3NMWliFcXcRAsfhAJoCPeKdacDDfZGCmWvl8OIyGx92SACfQUTH dnOiO33/2TRux5BgeoC3HwQ= =NWgK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Den Saturday 08 December 2007 00:00:03 skrev Pascal Bleser:
Gabriel . wrote:
The translation tool seems very interesting, it is possible to use the online tool (and have access to a 800k+ string database) or download the po file for local work. Also you can have a track of what file is being translated and by who, and more.
It's most probably a very nice tool, but using it is a big "no way" because it isn't opensource nor free.
But yeah, indeed, it would be great to have a tool that is both easy to use and potent enough to merge with upstream, because translation is an obvious topic where lots of people can contribute, even people who have less experience in the technical field (note that I said "less experience", not "no experience" ;)).
Personally I don't believe that it's necessarily a good idea to lower the barrier to entry beyond a certain point. Sure, contributing should be easy, but It can become _too_ easy. I think it's important to have some mechanisms for ensuring people getting involved have at least some degree of dedication, and that the coordinators have some control over who does what, when, why and how (team guidelines and such). Not saying a webinterface is a bad idea, but care for these issues is needed. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
At the point where we are with translation management, we should really consider a tool to facilitate the work. At the moment: * we use SVN manually * we have a separate web page for statistics * we don't receive communications about changes in .po files * already translated files are altered during operations * we use mixed .po formats (not suse specific, but still a problem) * team management is completely left to personal communication Simplifying the procedure is now a lot more important than before: now many languages have open translations, so translators are volunteers and not paid. As a consequence, providing them proper and easy tools is essential not to waste their time as it happens often now (repeated translations of the exact same stuff), and to keep them motivated. Dedication has nothing to do with solving issues not related to the work someone accepted (read .po formats, merging issues, sudden and continuous changes in .po...we discussed of these already). You may be dedicated, but if you see you're loosing too much time to do technical stuff not directly related to your real goal (translation in this case), your motivation goes down for sure. To conclude, each improvement is welcome in my opinion in the translation process, which is now quite manual. The fact that a tool is free or open counts a lot less, if it is a good tool. With kind regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Alberto Passalacqua kirjutas:
At the point where we are with translation management, we should really consider a tool to facilitate the work.
At the moment:
* we use SVN manually * we have a separate web page for statistics * we don't receive communications about changes in .po files * already translated files are altered during operations * we use mixed .po formats (not suse specific, but still a problem) * team management is completely left to personal communication
Simplifying the procedure is now a lot more important than before: now many languages have open translations, so translators are volunteers and not paid.
As a consequence, providing them proper and easy tools is essential not to waste their time as it happens often now (repeated translations of the exact same stuff), and to keep them motivated.
Dedication has nothing to do with solving issues not related to the work someone accepted (read .po formats, merging issues, sudden and continuous changes in .po...we discussed of these already). You may be dedicated, but if you see you're loosing too much time to do technical stuff not directly related to your real goal (translation in this case), your motivation goes down for sure.
To conclude, each improvement is welcome in my opinion in the translation process, which is now quite manual. The fact that a tool is free or open counts a lot less, if it is a good tool.
I'm not against online tools, but there are some hard requirements to fulfill. The first is that these tools should work parallel with existing system, because in opposite case we can loose many of professional or experienced translators who will never use such toys (and win a lot of wannabe translators knowing nothing about existing terminology and even spelling and grammar). Second point comes from previous, such tools should have strict commit and reviewing rights system. The thing that software is open or not, counts much. How the heck we could have some influence to not open tool development? Launchpad may be popular, but for us its a dead end. At this point of time, an open tool, Pootle (and its offline editor Pootling) is under heavy development and is tested by OpenOffice.org community for using as parallel interface for translation teams. When we had some clear points what we want to see as result, our community could help translate-tools team e.g. with svn-integration etc. ain --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-12-08 at 21:42 +0100, Alberto Passalacqua wrote:
At the point where we are with translation management, we should really consider a tool to facilitate the work.
At the moment:
* we use SVN manually * we have a separate web page for statistics * we don't receive communications about changes in .po files * already translated files are altered during operations * we use mixed .po formats (not suse specific, but still a problem) * team management is completely left to personal communication
Simplifying the procedure is now a lot more important than before: now many languages have open translations, so translators are volunteers and not paid.
Absolutely. Case examples: not every body in the team has commit rights (they may even not want them), thus they send their translated .po files to somebody else who has to commit them. This is slow and needs more work; right now the Spanish team is finishing 10.3, so speed is not important, but when the time comes to translate trunk it will be. Another problem is that the .po files should be updated now and then with possible new messages in the .pot files by running "make update-po". To do this I have to post in our private mail list a warning that in two days I'm going to do that, and please every body submit whatever files they have modified and halt work for a day. We can do this a Wednesday, but not a Friday, because the weekend is the productive translation time. It would be better if some tool on the server made the update-po on each file submitted, in the same operation as the submission. Or something special to trigger it, dunno. We would still have to do the general update-po, but the impact would be lessened. Another problem is that, in order to coordinate which person is translating which file, we use a special wiki page with a table listing every file, and where every body marks what files he/she has and is modifying, so that other translators pick different files, automatically. But this process is cumbersome and sometimes fails. A shared worksheet would be faster, perhaps. Or something else. Another problem we have is with large files, like update-desktop-files.es.po, which has 6000 messages, and we know for certain that many of them are badly translated. We could improve work if two or more people could work simultaneously on it, but I don't know how this could be done.
As a consequence, providing them proper and easy tools is essential not to waste their time as it happens often now (repeated translations of the exact same stuff), and to keep them motivated.
Dedication has nothing to do with solving issues not related to the work someone accepted (read .po formats, merging issues, sudden and continuous changes in .po...we discussed of these already). You may be dedicated, but if you see you're loosing too much time to do technical stuff not directly related to your real goal (translation in this case), your motivation goes down for sure.
To conclude, each improvement is welcome in my opinion in the translation process, which is now quite manual. The fact that a tool is free or open counts a lot less, if it is a good tool.
No, I prefer an open tool. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHW/xdtTMYHG2NR9URAp0sAJ48mq/APL29uUQ39MC4DzSjZZpz9ACeMbNN SM8HU++V9/TyNxn87UUlPCY= =OFUN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
"Carlos E. R." <robin.listas@telefonica.net> writes:
Another problem is that, in order to coordinate which person is translating which file, we use a special wiki page with a table listing every file, and where every body marks what files he/she has and is modifying, so that other translators pick different files, automatically. But this process is cumbersome and sometimes fails.
A shared worksheet would be faster, perhaps. Or something else.
We could make use of SVN file properties.
Another problem we have is with large files, like update-desktop-files.es.po, which has 6000 messages, and we know for certain that many of them are badly translated. We could improve work if two or more people could work simultaneously on it, but I don't know how this could be done.
If wanted we can split the file. We just need criteria on which we should split. I think we can base the split rules on the contents of msgctxt or msgid. -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-12-10 at 10:15 +0100, Karl Eichwalder wrote:
"Carlos E. R." <> writes:
Another problem is that, in order to coordinate which person is translating which file, we use a special wiki page with a table listing every file, and where every body marks what files he/she has and is modifying, so that other translators pick different files, automatically. But this process is cumbersome and sometimes fails.
A shared worksheet would be faster, perhaps. Or something else.
We could make use of SVN file properties.
Perhaps, but not everybody has commit permissions; in fact, some do not want to have them, perhaps afraid of spoiling something or who knows. In fact, I am afraid of svn. I'm afraid of goofing sometime and harming other people's work. Of course, the theory, and I suppose the practice, says that changes in svn are undo-able, but some times that's not so easy, as I found out myself once, when I wanted to revert a single file to an older version and couldn't: I had to erase it and then add it again to the svn. And that was about two or three hours investigation and work.
Another problem we have is with large files, like update-desktop-files.es.po, which has 6000 messages, and we know for certain that many of them are badly translated. We could improve work if two or more people could work simultaneously on it, but I don't know how this could be done.
If wanted we can split the file. We just need criteria on which we should split. I think we can base the split rules on the contents of msgctxt or msgid.
Well, yes, but that wouldn't be a replacement for a tool allowing two persons to work simultaneously on the same file. There is a cooperative editor, named "Gobby", but it doesn't understand .po syntax. I was just pointing what a tool like that would allow us to do. Just imagine! :-)~ For the time being, I could just hand split the file, distribute it within our team, and then join the pieces later on, when done. By the way... I told kbabel to sort alphabetically, for display, and I'm afraid that kbabel saved in that order (bug?). Separating by modules might not be possible now. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHXWHftTMYHG2NR9URAu6CAJoDW+aLu+8oDduG/zIFqLixfn5g0gCfWvHG ZvufOoMQJ9wF+fkIfcKk8UM= =xFf/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Hi, Launchpad is a nice tool for projects developed inside the tool. But when you need more, like export (to cvs,svn) or working with other format (ts), it does not provide too much comfort :-(. We will need to have also one more functionality, integration into the build service. With a proprietary tool there is only very small chance to have it. And I am not sure, if we want to use a proprietary tool. In the past we little played with tools like Pootle. No one from them matched our requirements without a lot of additional work. There are also some planes to create localization integration into build service. The work is still in planning stage and developers will need some input what they should implement. It would be also very nice to find somebody from localization community, who will be able to participate on the development. If you like Ruby, you are welcome. I think good start to prepare work for developers it to collect all our requirements on http://en.opensuse.org/OpenSUSE_Localization_Guide -- Klara Dne Friday 07 of December 2007 20:27:31 Gabriel . napsal(a):
I was talking with Elliot Murphy from Canonical regarding Launchpad (launchpad.net). For those who doesn't know Launchpad, it's a web tool to organize collaboration. Also is the Ubuntu development site (they host their source, translations, bugs, etc).
The translation tool seems very interesting, it is possible to use the online tool (and have access to a 800k+ string database) or download the po file for local work. Also you can have a track of what file is being translated and by who, and more.
One of the main thing I asked him was about svn support. He's reply was that Launchpad has native support to a version control tool called Bazaar, and it's possible to do continuous import from a svn repository.
Maybe we can get some ideas from there, or even use it.
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
participants (8)
-
Ain Vagula -
Alberto Passalacqua -
Carlos E. R. -
Gabriel . -
Karl Eichwalder -
Klára Cihlářová -
Martin Schlander -
Pascal Bleser