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

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

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

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

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

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

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

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

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

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

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

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

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

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