[opensuse-translation] Tools to help the translation teams

newer
[opensuse-translation] POAT - new...

older
[opensuse-translation] POAT not...

Vincent Untz

29 Feb 2008 29 Feb '08

16:50

Hi, Let me first introduce myself, since I just subscribed to this list. I'm a GNOME hacker, and with my new job, I'll be working on openSUSE. Since I want my desktop in a perfect french, I'm quite interested in translation, although I don't have time to translate. I've looked a bit about how the localization project in openSUSE work. It looks like it's working well right now, but there are always things to improve, I guess :-) Here are some rough ideas about where we might go in GNOME, or maybe just in the GNOME french translation team (it has not been widely discussed yet, hence the "might"). I'd love to know if the openSUSE translation teams would be interested in going the same way. Right now, in GNOME, we have only Damned Lies: http://l10n.gnome.org/ It's basically where we can get statistics about each translation, by languages/modules/modulesets/etc. It also enables the translators to download the latest version of the po file to complete the translation. I guess it's a bit similar to the current statistics page on i18n.opensuse.org, although Damned Lies seems to do a bit more In the french translation team, we also have vertimus: https://code.launchpad.net/vertimus (upstream project) http://gnomefr.traduc.org/suivi/ (server used for GNOME french translation) It's a tool to let the team work in a more efficient way. Basically, it lets people reserve a module for translation. When it's translated, the translator uploads a po file which is then proofreads by someone else. If everything is fine, it gets marked as "ready for commit" and someone with commit powers commits it. It gets all the statistics about modules from Damned Lies. We're trying to have the tool a bit more generic so it can be used by other teams. Now, we're also interested in pootle and transifex: http://translate.sourceforge.net/wiki/pootle/index http://fedoraproject.org/wiki/Features/Transifex https://hosted.fedoraproject.org/transifex Pootle allows translators to translate po files in a web application, with translation memory and other cool stuff. Transifex makes it easier to commit a file, using a web form. (this simplifies things since it doesn't require svn/cvs/git/blabla access for translators and they don't have to learn about vcs if they don't want too). Note that we've not integrated those two tools yet, but they look promising to us. Integrating Transifex shouldn't be too hard. Pootle is harder, though. Oh, and the goal would be to have those tools optional, so translators can still use svn if they don't like Transifex. On the openSUSE side, I have the feeling that we could make use of Transifex in the short term, and maybe vertimus too. And perhaps Pootle in the long term. I'd like to hear what you think of all this. I hope I didn't write too many stupid things ;-) Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Show replies by date

Carlos E. R.

2 Mar 2 Mar

12:23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2008-02-29 at 17:50 +0100, Vincent Untz wrote: [ Third resend - the list silently discards my email :-( ]

...

Hi,

Let me first introduce myself, since I just subscribed to this list. I'm a GNOME hacker, and with my new job, I'll be working on openSUSE. Since I want my desktop in a perfect french, I'm quite interested in translation, although I don't have time to translate.

Welcome! ...

...

In the french translation team, we also have vertimus: https://code.launchpad.net/vertimus (upstream project) http://gnomefr.traduc.org/suivi/ (server used for GNOME french translation) It's a tool to let the team work in a more efficient way. Basically, it lets people reserve a module for translation. When it's translated, the translator uploads a po file which is then proofreads by someone else. If everything is fine, it gets marked as "ready for commit" and someone with commit powers commits it. It gets all the statistics about modules from Damned Lies. We're trying to have the tool a bit more generic so it can be used by other teams.

This sounds very interesting. [...] What I miss is a... perhaps some screen shots of vertimus at work. I had a look under http://gnomefr.traduc.org/suivi/, but I can't see how it works, perhaps because I'm not a french translator (obviously.) A member of the Spanish team (Gabriel) has designed, and we are testing, a web tool for a similar task, and, at first glance, it would seem we are duplicating efforts. We have a test site, but I won't publish it here (I leave that for him). So, I think it would be interesting to be able to really compare capabilities.

...

Now, we're also interested in pootle and transifex: http://translate.sourceforge.net/wiki/pootle/index http://fedoraproject.org/wiki/Features/Transifex https://hosted.fedoraproject.org/transifex Pootle allows translators to translate po files in a web application, with translation memory and other cool stuff. Transifex makes it easier to commit a file, using a web form. (this simplifies things since it doesn't require svn/cvs/git/blabla access for translators and they don't have to learn about vcs if they don't want too).

Interesting. I have seen questions about similar tools.

...

Note that we've not integrated those two tools yet, but they look promising to us. Integrating Transifex shouldn't be too hard. Pootle is harder, though. Oh, and the goal would be to have those tools optional, so translators can still use svn if they don't like Transifex.

On the openSUSE side, I have the feeling that we could make use of Transifex in the short term, and maybe vertimus too. And perhaps Pootle in the long term. I'd like to hear what you think of all this.

Very interesting :-)

...

I hope I didn't write too many stupid things ;-)

No! :-) Actually, there is another tool I'm very interested in: a man page editor. And no, I don't consider vi or emacs as valid editors (I come from long time usage of Borland IDEs, word star style: so I simply can not use neither vi or emacs proficiently) Programmers seem to be happy using a plain text editor to create troff markup for man pages. But translators are not programmers, or not all of them (I was a msdos/win programmer, I'm not a linux programmer: thus I translate for linux). There are no tools for this. There is manedit (http://www.battlefieldlinux.com/wolfpack/ManEdit/) which is old and not actively maintained: for instance, it lacks utf8 support, and has to be fired from a latin1 xterm or the keyboard fails. It doesn't have spell checking, for instance, and does not understand some of the tokens. mcedit understands the syntax and colours it: but it gives the troff tokens to the speller, which is a real nuisance. jstar understands the syntax as well, but refuses to use the system aspell. LyX would be very nice: but the "manpage" template depends on linuxdoc and doesn't work at all. Hasn't worked in years!, in fact, and there is no substitute manpage template for docbook. No, writing a manpage in docbook XML is not a good idea. I tried. I know nothing of XML editing, found it too hard, harder than plain troff, and run away. So... if somebody at Novell, involved in translations, could convince some developers to develop a a WYSIWYG man page editor (text mode is fine!), with spell check support (plus local dictionary), then we could start convincing translators to actively translate manpages: some of them are really obsolete. O:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHypw5tTMYHG2NR9URAmefAKCQ8im6WphZdaEm/wQBFJxRobK79wCffzS2 aCaIcFxmhaMvJ1OyzVOXR2E= =KuHC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder

3 Mar 3 Mar

09:38

Vincent Untz writes: Hi and thanks for joining! I'm all for improvements.

...

It's a tool to let the team work in a more efficient way. Basically, it lets people reserve a module for translation.

For larger teams that's surely interesting. Also the proofreading stage is very important, but human resources could be the bottle-neck in this area. Whether pootle, transifex, and similar tools could be a help, surely depends on those who actually translate all these strings. And do not forget that for new tools we will need admins and maintainers. OmegaT also seems to offer interesting feature: http://www.omegat.org/

...

Oh, and the goal would be to have those tools optional, so translators can still use svn if they don't like Transifex.

At least for the moment, that would be very important. -- 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

Vincent Untz

18 Mar 18 Mar

12:12

Hi, Le vendredi 29 février 2008, à 17:50 +0100, Vincent Untz a écrit :

...

On the openSUSE side, I have the feeling that we could make use of Transifex in the short term, and maybe vertimus too. And perhaps Pootle in the long term. I'd like to hear what you think of all this.

I'd like to propose a Summer of Code project to integrate some of those tools (or others) so they can easily be used together. I'd be okay to mentor it, but before adding the idea to the list of openSUSE ideas, I want to make sure it makes sense to people here. Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Martin Schlander

13:32

Tirsdag den 18. Marts 2008 13:12:06 skrev Vincent Untz:

...

Le vendredi 29 février 2008, à 17:50 +0100, Vincent Untz a écrit :

...
On the openSUSE side, I have the feeling that we could make use of Transifex in the short term, and maybe vertimus too. And perhaps Pootle in the long term. I'd like to hear what you think of all this.

I'd like to propose a Summer of Code project to integrate some of those tools (or others) so they can easily be used together. I'd be okay to mentor it, but before adding the idea to the list of openSUSE ideas, I want to make sure it makes sense to people here.

As long as the tools do not allow/encourage people to start doing things without getting in touch with the coordinator first, I'm not against it. On the other hand I'm happy with the tools we have, so it's not something that I'd consider very important. Now if someone could make as-you-type-spellcheck work in LoKalize, _that_ would be something :-) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

13:50

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-03-18 at 14:32 +0100, Martin Schlander wrote:

...

On the other hand I'm happy with the tools we have, so it's not something that I'd consider very important.

But we aren't, and have said so on ocassion. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH38jPtTMYHG2NR9URAhhjAJ46xljcgjUciUVTtdCG5+3tEtAUMACfZLvN 77+nUwDlzDPqFTho1/Fxb6Q= =VpYG -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Alberto Passalacqua

16:06

...

As long as the tools do not allow/encourage people to start doing things without getting in touch with the coordinator first, I'm not against it.

On the other hand I'm happy with the tools we have, so it's not something that I'd consider very important.

Now if someone could make as-you-type-spellcheck work in LoKalize, _that_ would be something :-)

I agree with Martin on the whole line. I'm personally happy with the current tools too. The only problems I see is not in doing translations or in organising them for the translation team. It's in coordinating with developers to avoid repetitive work (read: strings changed without a reason, mainly with cosmetic motivations). For the rest, a spreadsheet with "you do this, you do that, and I do the rest" or something like POAT is more than what we need. I'm not sure if it's the case, but it's better to clarify. I'm against online translations tools meant as an online replacement of poedit/lokalize. The reasons are simple: you need a connection, you work on the original files, and it makes more complex to fix issues if someone does a mess. With kind regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder

16:26

Alberto Passalacqua writes:

...

It's in coordinating with developers to avoid repetitive work (read: strings changed without a reason, mainly with cosmetic motivations).

Even if it looks this way, English string changes are probably due to bugs or bad English or because of some kind of normalization. Otherwise, thanks for comments! -- 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

Alberto Passalacqua

16:36

Il giorno mar, 18/03/2008 alle 17.26 +0100, Karl Eichwalder ha scritto:

...

Alberto Passalacqua writes:

...
It's in coordinating with developers to avoid repetitive work (read: strings changed without a reason, mainly with cosmetic motivations).

Even if it looks this way, English string changes are probably due to bugs or bad English or because of some kind of normalization.

Otherwise, thanks for comments!

Hello Karl, to clarify, I really didn't mean it a negative comment for you, your team or the developers. I know it's not so easy to keep all string frozen when developing (ehm, I code myself, and I would probably be one of the worst developer for translators ;-)). I only wanted to point out one possible improvable aspect. :-) With kind regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

22:42

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-03-18 at 11:06 -0500, Alberto Passalacqua wrote:

...

...
As long as the tools do not allow/encourage people to start doing things without getting in touch with the coordinator first, I'm not against it.

On the other hand I'm happy with the tools we have, so it's not something that I'd consider very important.

Now if someone could make as-you-type-spellcheck work in LoKalize, _that_ would be something :-)

I agree with Martin on the whole line.

I'm personally happy with the current tools too. The only problems I see is not in doing translations or in organising them for the translation team. It's in coordinating with developers to avoid repetitive work (read: strings changed without a reason, mainly with cosmetic motivations). For the rest, a spreadsheet with "you do this, you do that, and I do the rest" or something like POAT is more than what we need.

POAT has been created precisely because the current tools are insuficient. And we still need something allowing an asignee to upload the translation file he has been assigned and no more - and subversion does not appear to be the answer. Other translation projects use an email robot for this. More... kbabel is not mantained and has big bugs, not to mention missing features.

...

I'm not sure if it's the case, but it's better to clarify. I'm against online translations tools meant as an online replacement of poedit/lokalize.

Me too. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4EVDtTMYHG2NR9URAlDuAJoC5nP0r6w0LZWcmKvdZI1MnjTdGACeLK33 Er+5GKVjWN+4u+GcuYXpRu0= =CSXl -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Martin Schlander

23:04

Tirsdag den 18. Marts 2008 23:42:10 skrev Carlos E. R.:

...

More... kbabel is not mantained and has big bugs, not to mention missing features.

KBabel is being replaced by LoKalize. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

19 Mar 19 Mar

00:05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-19 at 00:04 +0100, Martin Schlander wrote:

...

Tirsdag den 18. Marts 2008 23:42:10 skrev Carlos E. R.:

...
More... kbabel is not mantained and has big bugs, not to mention missing features.

KBabel is being replaced by LoKalize.

Wasn't going to be Kaider? Is it usable in in 10.3? Is it good? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4FjHtTMYHG2NR9URAslLAJ4sTWifgJCOfbIj6A3lM4120laaZQCfZjmO dwEMu9NORVlFWfDmkacQEvQ= =k2xc -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Martin Schlander

10:36

Onsdag den 19. Marts 2008 01:05:15 skrev Carlos E. R.:

...

The Wednesday 2008-03-19 at 00:04 +0100, Martin Schlander wrote:

...
KBabel is being replaced by LoKalize.

Wasn't going to be Kaider?

Is it usable in in 10.3?

Is it good?

KAider was renamed to LoKalize recently. It's available for 10.3 as a "backport" for KDE4.0 http://download.opensuse.org/repositories/KDE:/KDE4:/STABLE:/Community/openS... And as a KDE4.1/trunk package http://download.opensuse.org/repositories/KDE:/KDE4:/UNSTABLE:/Desktop/openS... It's still a work in progress, but it's very promising and has always been solid for me. But the lack of as-you-type spellchecking is what holds me back from using it as the primary editor. The developer is applying to work on it as a GSoC project again: http://lists.kde.org/?l=kde-i18n-doc&m=120591916632745&w=2 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

11:41

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-19 at 11:36 +0100, Martin Schlander wrote:

...

...
Wasn't going to be Kaider?

Is it usable in in 10.3?

Is it good?

KAider was renamed to LoKalize recently.

It's available for 10.3 as a "backport" for KDE4.0 http://download.opensuse.org/repositories/KDE:/KDE4:/STABLE:/Community/openS...

I'll try this.

...

And as a KDE4.1/trunk package http://download.opensuse.org/repositories/KDE:/KDE4:/UNSTABLE:/Desktop/openS...

It's still a work in progress, but it's very promising and has always been solid for me. But the lack of as-you-type spellchecking is what holds me back from using it as the primary editor.

The developer is applying to work on it as a GSoC project again: http://lists.kde.org/?l=kde-i18n-doc&m=120591916632745&w=2

Good. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4Pv4tTMYHG2NR9URArjPAJ4+U03MGRWUypqTTyhqIF6w4r0GWgCfWA3A W9fRT5j00sA/Y0Jpg27LoDo= =sR1k -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Alberto Passalacqua

01:35

...

POAT has been created precisely because the current tools are insuficient.

And we still need something allowing an asignee to upload the translation file he has been assigned and no more - and subversion does not appear to be the answer. Other translation projects use an email robot for this.

Persolly, I don't want and don't need this. I don't think that allowing all the team members to commit is what coordinators want. I prefer they send the translated file to me, then I proofread it and only after that I commit.

...

More... kbabel is not mantained and has big bugs, not to mention missing features.

Replaced by lokalize in kde 4 :-) With kind regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

11:29

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-03-18 at 20:35 -0500, Alberto Passalacqua wrote:

...

...
POAT has been created precisely because the current tools are insuficient.

And we still need something allowing an asignee to upload the translation file he has been assigned and no more - and subversion does not appear to be the answer. Other translation projects use an email robot for this.

Persolly, I don't want and don't need this. I don't think that allowing all the team members to commit is what coordinators want.

Each team is different. First, we don't have a coordinator, he is missing. Then, not everybody has commit access, so the rest of the team email their translated files to the three that do have commit permission, and we simply upload it, without proofreading, which is done later. As it is, committing files puts some load on these people, and the translator has to wait perhaps a day or two till this is done. Thus, the idea to use a robot. The translator is given permission to submit to the robot just the files he is been translating. He/she just emails the file to the robot, the robot does some simple verification, and submits via subversion. This we don't have yet, and I'm unsure if somebody is working on it. As I say, some translation projects have had one for years.

...

...
More... kbabel is not mantained and has big bugs, not to mention missing features.

Replaced by lokalize in kde 4 :-)

I will have to install kde4. I hope it runs under gnome, too. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4PkqtTMYHG2NR9URAsGPAKCVtZJCK0j/xLJ88ga1zSz20pwLjwCffKy1 zNi26k5sBx9LExOdYMHDidc= =PfQE -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Vincent Untz

00:09

Le mardi 18 mars 2008, à 11:06 -0500, Alberto Passalacqua a écrit :

...

...
As long as the tools do not allow/encourage people to start doing things without getting in touch with the coordinator first, I'm not against it.

On the other hand I'm happy with the tools we have, so it's not something that I'd consider very important.

Now if someone could make as-you-type-spellcheck work in LoKalize, _that_ would be something :-)

I agree with Martin on the whole line.

I'm personally happy with the current tools too. The only problems I see is not in doing translations or in organising them for the translation team. It's in coordinating with developers to avoid repetitive work (read: strings changed without a reason, mainly with cosmetic motivations). For the rest, a spreadsheet with "you do this, you do that, and I do the rest" or something like POAT is more than what we need.

It's a topic a bit more complex than "do we need it?". From my experience, using a tool like vertimus totally changed the way the french translation team (GNOME one, not openSUSE one) works. It suddenly was easier to understand what was happening, easier to know the status of each translation (under translating, waiting for proofreading, etc.), and also it helped attract new contributors. And the translation really improved a lot because of this. Now, if we also make it easier to commit things, or easier to translate with a specific app, this will remove a bottleneck, or lower the barrier of entry. And again, there will be more contributors.

...

I'm not sure if it's the case, but it's better to clarify. I'm against online translations tools meant as an online replacement of poedit/lokalize. The reasons are simple: you need a connection, you work on the original files, and it makes more complex to fix issues if someone does a mess.

Again, the plan would be to have the use of all those tools optional: you're not forced to use them if you don't want to use them. But having them improves the translation process and the translations in the long term. Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

01:15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-19 at 01:09 +0100, Vincent Untz wrote:

...

Again, the plan would be to have the use of all those tools optional: you're not forced to use them if you don't want to use them. But having them improves the translation process and the translations in the long term.

Exactly. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4GlHtTMYHG2NR9URAgncAKCLnxifHoRS870+WRXgVaifLOqELQCfTd0C qx9RGVaCmT/Mu/ErtBwm648= =jAfb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Alberto Passalacqua

01:55

...

It's a topic a bit more complex than "do we need it?". From my experience, using a tool like vertimus totally changed the way the french translation team (GNOME one, not openSUSE one) works. It suddenly was easier to understand what was happening, easier to know the status of each translation (under translating, waiting for proofreading, etc.), and also it helped attract new contributors. And the translation really improved a lot because of this.

Well, to be honest, after a period of "not finding translators", I had to reject some requests. Translation is an easy task by definition, so it's not hard to attracto contributors, especially if the project is well know, if it's not too big, and if there's a reward (opensuse boxes seem very effective :P). I don't see what's complex in doing something like: svn checkout url once, and then svn update the rest of the time. Of course integrating it in lokalize and poedit would be nice, but it's an enhancement more than a real need. About the applications, a simple tutorial on the wiki did the trick in my case (for the Italian team).

...

Now, if we also make it easier to commit things, or easier to translate with a specific app, this will remove a bottleneck, or lower the barrier of entry. And again, there will be more contributors.

Yes. But I don't agree with the "everyone can commit" policy.

...

Again, the plan would be to have the use of all those tools optional: you're not forced to use them if you don't want to use them. But having them improves the translation process and the translations in the long term.

As I said, I don't believe in the fact that the problem is on the translators side. I would really concentrate the effort in imposing _hard_ string freeze. The lack of respect of a string freeze is what, in my experience, made me lose more time. For the rest, the management of the translation process is basic, and can be summed up this way: * Count the strings. * Divide by the number of translators roughly. * Assign them the files * Translate * Proofread * Commit The only tasks done by non-coordinators are "Translate" and "Proofread". For the rest, it's really a question of opening OOo-calc and doing some sum. What you say might be true when there are a lot of strings and applications to translate like in KDE or GNOME, but for openSUSE it seems really a more costly investment than beneficial. With kind regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Vincent Untz

09:45

Le mardi 18 mars 2008, à 20:55 -0500, Alberto Passalacqua a écrit :

...

...
It's a topic a bit more complex than "do we need it?". From my experience, using a tool like vertimus totally changed the way the french translation team (GNOME one, not openSUSE one) works. It suddenly was easier to understand what was happening, easier to know the status of each translation (under translating, waiting for proofreading, etc.), and also it helped attract new contributors. And the translation really improved a lot because of this.

Well, to be honest, after a period of "not finding translators", I had to reject some requests. Translation is an easy task by definition, so it's not hard to attracto contributors, especially if the project is well know, if it's not too big, and if there's a reward (opensuse boxes seem very effective :P).

I wouldn't say translation is an easy task, it's quite hard (at least for me ;-)) to do high-quality translations. Getting all translations consistent wrt terms being used, for example, is not easy. Glad to see that you're able to attract new contributors, though. If you have to reject some requests, maybe you can redirect them to some upstream projects (GNOME, KDE, translation project, etc.)?

...

I don't see what's complex in doing something like:

svn checkout url

once, and then

svn update

the rest of the time. Of course integrating it in lokalize and poedit would be nice, but it's an enhancement more than a real need.

Well, I'm glad that you don't need any change. But I'd be surprised to hear that every translators feels comfortable with svn. To make it clear: if I had time to translate, I wouldn't need most of those tools either. It doesn't mean other people don't need it.

...

About the applications, a simple tutorial on the wiki did the trick in my case (for the Italian team).

...
Now, if we also make it easier to commit things, or easier to translate with a specific app, this will remove a bottleneck, or lower the barrier of entry. And again, there will be more contributors.

Yes. But I don't agree with the "everyone can commit" policy.

I didn't say everybody would be able to commit :-) But it'd be easier to allow people to commit if needed, and they wouldn't have to understand svn.

...

...
Again, the plan would be to have the use of all those tools optional: you're not forced to use them if you don't want to use them. But having them improves the translation process and the translations in the long term.

As I said, I don't believe in the fact that the problem is on the translators side. I would really concentrate the effort in imposing _hard_ string freeze. The lack of respect of a string freeze is what, in my experience, made me lose more time.

I agree that a hard string freeze would help. Note that one of the tool I'm talking about (damned-lies) automatically sends a mail when a freeze is broken to tell about a new string. Very useful.

...

For the rest, the management of the translation process is basic, and can be summed up this way:

* Count the strings. * Divide by the number of translators roughly. * Assign them the files * Translate * Proofread * Commit

The only tasks done by non-coordinators are "Translate" and "Proofread". For the rest, it's really a question of opening OOo-calc and doing some sum.

That's one way to organize the work, yes. My point is that it might not be the best way for everybody, even though it's fine for you.

...

What you say might be true when there are a lot of strings and applications to translate like in KDE or GNOME, but for openSUSE it seems really a more costly investment than beneficial.

Well, why would it be costly for you if it doesn't change anything to your workflow? I mean, it would cost me time, but it's fine since I'm willing to do this because I'm convinced it's something we have to do. FWIW, looking at the stats, there are 31607 strings. That's huge. For reference, the official GNOME modules contain around 40000 strings. Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

11:28

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-19 at 10:45 +0100, Vincent Untz wrote:

...

Glad to see that you're able to attract new contributors, though. If you have to reject some requests, maybe you can redirect them to some upstream projects (GNOME, KDE, translation project, etc.)?

Which is what some in my team are doing at the moment.

...

Well, I'm glad that you don't need any change. But I'd be surprised to hear that every translators feels comfortable with svn. To make it clear: if I had time to translate, I wouldn't need most of those tools either. It doesn't mean other people don't need it.

More than half our team do not want svn access. They either don't like/understand it, or don't want the responsibility. They concentrate on translate, which is not a simple task if you do it well and dedicate time and effort, and you are not a professional translator.

...

...
What you say might be true when there are a lot of strings and applications to translate like in KDE or GNOME, but for openSUSE it seems really a more costly investment than beneficial.

Well, why would it be costly for you if it doesn't change anything to your workflow? I mean, it would cost me time, but it's fine since I'm willing to do this because I'm convinced it's something we have to do.

And we will be thank full ;-)

...

FWIW, looking at the stats, there are 31607 strings. That's huge. For reference, the official GNOME modules contain around 40000 strings.

My team spent a lot of time reviewing many of those, even those translated on previous years, to ensure consistency. We spent about three months. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4PjbtTMYHG2NR9URAlFgAJsFU3x26L8QQr6+4dkk+gU1sfKTEwCdFk3d IdFTqvRpTfQfyMLzDU/Uq2g= =are7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Alberto Passalacqua

13:54

...

Glad to see that you're able to attract new contributors, though. If you have to reject some requests, maybe you can redirect them to some upstream projects (GNOME, KDE, translation project, etc.)?

Sure. It's what I did. Someone is helping on openSUSE wiki, someone helps on other projects.

...

Well, I'm glad that you don't need any change. But I'd be surprised to hear that every translators feels comfortable with svn. To make it clear: if I had time to translate, I wouldn't need most of those tools either. It doesn't mean other people don't need it.

What I meant is that I don't see how a tool can reduce the learning curve of two commands, that can be used really in a mechanical way, even if you don't understand anything about svn (I don't really know much about if, just checkout, commit and update ^^). Anyway, if someone has some good idea, I'm not against it in principle, of course.

...

That's one way to organize the work, yes. My point is that it might not be the best way for everybody, even though it's fine for you.

Of course it can be improved in many ways. I'm just trying to say "keep things simple", because what it seems to me is that we are just adding levels of complexity (more tools) instead of removing obstacles.

...

Well, why would it be costly for you if it doesn't change anything to your workflow? I mean, it would cost me time, but it's fine since I'm willing to do this because I'm convinced it's something we have to do.

I didn't mean it's costly for me. I meant it's costly for openSUSE and who will implement it, considering that IMHO there are a lot of most urgent aspects the openSUSE project should fix before thinking to translations (read a good high available download centre, QA on patches, and, I know it's a dream, a "stabilization" release.)

...

FWIW, looking at the stats, there are 31607 strings. That's huge. For reference, the official GNOME modules contain around 40000 strings.

Yes, but they're not completely untranslated. Memory does a good job :-) Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

16:14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-19 at 08:54 -0500, Alberto Passalacqua wrote:

...

Of course it can be improved in many ways. I'm just trying to say "keep things simple", because what it seems to me is that we are just adding levels of complexity (more tools) instead of removing obstacles.

To some translators those new tools are needed to simplify things. For instance, some translators do not have a full or even partial file tree. They just have the single file.po they are translating... svn is useless for them.

...

...
FWIW, looking at the stats, there are 31607 strings. That's huge. For reference, the official GNOME modules contain around 40000 strings.

Yes, but they're not completely untranslated. Memory does a good job :-)

You shouldn't trust memory. We found some strings horribly translated... and they were not marked fuzzy. Those bad strings will reside in "memory" for ever... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4TvUtTMYHG2NR9URAg3+AKCUrdP6gSNLiRTGxdz+H7blkBP9rwCfQUZT qw6a3N9K3ucpSjO/k+AgabI= =B36A -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder

16:25

"Carlos E. R." writes:

...

To some translators those new tools are needed to simplify things.

For instance, some translators do not have a full or even partial file tree. They just have the single file.po they are translating... svn is useless for them.

Yes, and as long as the new tools are optional, I'm all for it. All our teams are very special, from single person teams to up to 10 persons everything is available :)

...

...
...
FWIW, looking at the stats, there are 31607 strings. That's huge. For reference, the official GNOME modules contain around 40000 strings.

Yes, but they're not completely untranslated. Memory does a good job :-)

You shouldn't trust memory. We found some strings horribly translated... and they were not marked fuzzy. Those bad strings will reside in "memory" for ever...

That's not the truth for the memory files available within our SVN. I update them from time to time (replacing old translations with new ones) and I wouldn't mind if team members would do it also for their language, if they see the need. 50-tools/lcn-make-memory.sh is now also available, finally ;) For yast, you can use 50-tools/y2-make-memmory.sh. I recommend to make use of the --add switch most of the time. lcn-make-memory.sh is running right now globally. -- 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

Carlos E. R.

22:46

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-19 at 17:25 +0100, Karl Eichwalder wrote:

...

"Carlos E. R." <> writes:

...
To some translators those new tools are needed to simplify things.

For instance, some translators do not have a full or even partial file tree. They just have the single file.po they are translating... svn is useless for them.

Yes, and as long as the new tools are optional, I'm all for it.

Absolutely.

...

All our teams are very special, from single person teams to up to 10 persons everything is available :)

I suppose that's to be expected. :-)

...

...
You shouldn't trust memory. We found some strings horribly translated... and they were not marked fuzzy. Those bad strings will reside in "memory" for ever...

That's not the truth for the memory files available within our SVN. I update them from time to time (replacing old translations with new ones) and I wouldn't mind if team members would do it also for their language, if they see the need. 50-tools/lcn-make-memory.sh is now also available, finally ;) For yast, you can use 50-tools/y2-make-memmory.sh. I recommend to make use of the --add switch most of the time.

I see. Which means I made a mistake when updating the trunk tree from our recently fully translated 10.3 tree, because I didn't update the memory file. Didn't know about that.

...

lcn-make-memory.sh is running right now globally.

I'll have to add this to my notes. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4ZfOtTMYHG2NR9URAlHzAJ9U6YyEQ8PebBvUukzQ71K3YiEK8ACfeaq1 ooOah6ryU31dWQb+TgeuPZs= =GKaC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder

20 Mar 20 Mar

07:33

Am Wed 19 Mar 2008 11:46:38 PM CET schrieb "Carlos E. R." :

...

Which means I made a mistake when updating the trunk tree from our recently fully translated 10.3 tree, because I didn't update the memory file. Didn't know about that.

I never told you about it ;-p

...

...
lcn-make-memory.sh is running right now globally.

I'll have to add this to my notes.

But be warned, there is still a subtle bug hidden ;( if the same msgid exists more than once and it is translated differently, the translation first found goes into the memory file. I thing I'd like to detect such clashes, remove the msgid (temporarily) from the memory file, and let it evaluate by the translator. If the msgid is translated differently on purpose, we must ask the developer to add msgctxt or a "prefix" to the string. Otherwise the translator must is encouraged to unify the translation (msgstr). I hope you can get what I want to say ;) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Martin Schlander

08:00

Torsdag den 20. Marts 2008 08:33:48 skrev Karl Eichwalder:

...

I thing I'd like to detect such clashes, remove the msgid (temporarily) from the memory file, and let it evaluate by the translator.

I thought work was being done to make all memory translations appears as fuzzy, and hence, letting all memory translations be evaluated by the translator --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Martin Schlander

08:05

Torsdag den 20. Marts 2008 09:00:46 skrev Martin Schlander:

...

Torsdag den 20. Marts 2008 08:33:48 skrev Karl Eichwalder:

...
I thing I'd like to detect such clashes, remove the msgid (temporarily) from the memory file, and let it evaluate by the translator.

I thought work was being done to make all memory translations appears as fuzzy, and hence, letting all memory translations be evaluated by the translator

.. or at least being offered as a 'per team option'. Depending on whether the team prefers a little less quality or a little less work. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder

08:58

Martin Schlander writes:

...

Torsdag den 20. Marts 2008 08:33:48 skrev Karl Eichwalder:

...
I thing I'd like to detect such clashes, remove the msgid (temporarily) from the memory file, and let it evaluate by the translator.

I thought work was being done to make all memory translations appears as fuzzy, and hence, letting all memory translations be evaluated by the translator

Yes, that's also still on our agenda. But here I'm now discussing what should go _into_ the memories, not how to make use of them ;) Martin Schlander writes:

...

.. or at least being offered as a 'per team option'. Depending on whether the team prefers a little less quality or a little less work.

Yes, something along these lines. Thanks for the reminder! -- 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

Carlos E. R.

16:10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2008-03-20 at 09:58 +0100, Karl Eichwalder wrote:

...

Martin Schlander <> writes:

...
Torsdag den 20. Marts 2008 08:33:48 skrev Karl Eichwalder:

...
I thing I'd like to detect such clashes, remove the msgid (temporarily) from the memory file, and let it evaluate by the translator.

I thought work was being done to make all memory translations appears as fuzzy, and hence, letting all memory translations be evaluated by the translator

Yes, that's also still on our agenda. But here I'm now discussing what should go _into_ the memories, not how to make use of them ;)

Martin Schlander <> writes:

...
.. or at least being offered as a 'per team option'. Depending on whether the team prefers a little less quality or a little less work.

Yes, something along these lines. Thanks for the reminder!

That sounds very nice. Now, where do we have to click to choose the option? (ducking and running) :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4ox5tTMYHG2NR9URAp5aAJ907haH/hggLf7eXL8ISiFbY8k9qgCghH2H KqEg4zVjw9X6cYTN6iBBXQM= =AEoh -----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.

16:06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2008-03-20 at 08:33 +0100, Karl Eichwalder wrote:

...

Am Wed 19 Mar 2008 11:46:38 PM CET schrieb "Carlos E. R." <>:

...
Which means I made a mistake when updating the trunk tree from our recently fully translated 10.3 tree, because I didn't update the memory file. Didn't know about that.

I never told you about it ;-p

True! :-)

...

...
...
lcn-make-memory.sh is running right now globally.

I'll have to add this to my notes.

But be warned, there is still a subtle bug hidden ;( if the same msgid exists more than once and it is translated differently, the translation first found goes into the memory file.

Yes...

...

I thing I'd like to detect such clashes, remove the msgid (temporarily) from the memory file, and let it evaluate by the translator. If the msgid is translated differently on purpose, we must ask the developer to add msgctxt or a "prefix" to the string. Otherwise the translator must is encouraged to unify the translation (msgstr).

I hope you can get what I want to say ;)

Yep. Things are quite more complex than what seen on the surface. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4ouhtTMYHG2NR9URAm++AJ9UnR7/kJ7ZgtfRzMenD9HoDp5ZHwCgljbe lQg15vxL8UhYW7nzsaHAiSk= =gYHv -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Alberto Passalacqua

19 Mar 19 Mar

17:57

...

To some translators those new tools are needed to simplify things.

For instance, some translators do not have a full or even partial file tree. They just have the single file.po they are translating... svn is useless for them.

This is a "bit" surprising. But well...OK.

...

You shouldn't trust memory. We found some strings horribly translated... and they were not marked fuzzy. Those bad strings will reside in "memory" for ever...

I don't. But it's without a doubt of great help. Without it you should rewrite everything every time, while with "memory" a proofread is enough. Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Carlos E. R.

22:38

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-19 at 12:57 -0500, Alberto Passalacqua wrote:

...

...
To some translators those new tools are needed to simplify things.

For instance, some translators do not have a full or even partial file tree. They just have the single file.po they are translating... svn is useless for them.

This is a "bit" surprising. But well...OK.

There are all kinds of people :-)

...

...
You shouldn't trust memory. We found some strings horribly translated... and they were not marked fuzzy. Those bad strings will reside in "memory" for ever...

I don't. But it's without a doubt of great help. Without it you should rewrite everything every time, while with "memory" a proofread is enough.

Yes, true. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4ZX4tTMYHG2NR9URAovpAJ0XloMmK5W40FKgfx51f7Y0xY5BJgCdH8/b ZVmtuCiTVZ24PYu7GMbST3E= =hTJP -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Vincent Untz

18:40

Le mercredi 19 mars 2008, à 08:54 -0500, Alberto Passalacqua a écrit :

...

...
FWIW, looking at the stats, there are 31607 strings. That's huge. For reference, the official GNOME modules contain around 40000 strings.

Yes, but they're not completely untranslated. Memory does a good job :-)

They're not completely untranslated in your language (and mine). Not in all languages. There are lots of other languages out there that, I hope, would benefit from what I call an "improved workflow" ;-) Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

5885

Age (days ago)

5905

Last active (days ago)

List overview

Download

33 comments

5 participants

participants (5)

Alberto Passalacqua
Carlos E. R.
Karl Eichwalder
Martin Schlander
Vincent Untz