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

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

-----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

-----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