Translating Audacity on Transifex or similar

[Beluga]

There has been discussion on the mailing list (part 2 of discussion) about making the translation process more efficient with the help of Transifex. I'm posting here, because I don't use mailing lists myself.

One of the first comments was: "But I don't feel comfortable using a non GPL tool, as it seems to be the case in the mentioned site."
Let's take a look at the Transifex intro:

Transifex Community Edition is an open-source product, developed in the open with its code freely available under the GPL. Planning, development and bug reporting takes place at the development site of http://code.transifex.com/

Other concerns were: "Build system should be modified to keep all translations on tx server"
This isn't needed, because Transifex can automatically update the English source file from a URL and the current unofficial Audacity translation project on Transifex already does this. Updates are done around morning GMT time every day I think.

"All credits from header of PO should be added to the messages themselves (tx strips history and all translator comments from file)."
This is a good point.

"Modification of build system (see 1) makes testing in the arbitrary moment of time somewhat problematic as txclient is not packaged by some systems."
"I do not know how well it works on Windows and Mac."
Tx command line client works just fine on Windows, I can confirm. It makes translation management by devs very simple: just mirror the Transifex project on your computer and then tx pull whenever you like. This, I feel, is the most obvious benefit - reducing the time needed in management.

As we already have an active Transifex project, I suggest using it for the time being and people are welcome to evaluate other options. I am now a co-maintainer of the unofficial project so I can make Gale a maintainer and he can try out the command line client.

One very strong candidate for a platform is the MediaWiki translate extension: https://www.mediawiki.org/wiki/MLEB
It would of course be cool to translate the Audacity wiki with the extension, but it can actually be used to translate anything! The people behind the extension are using it even for translating KDE (yes, the whole shebang) into Finnish: http://l10n.laxstrom.name/wiki/KDE_SC_4.10
Being MediaWiki, it has superior history features. On Transifex, you have to go string by string to see who modified what.
The extension supports Gettext files out of the box.
You can try it out here, if you register an account: http://translatewiki.net/
Dev blog: http://laxstrom.name/blag/

The question is, however, does Audacity host its Wiki on Sourceforge? If yes, it might be too slow to use for translating absolutely everything.

[Gale Andrews]

Hello,

There was no developer support for moving to Transifex so it won't happen.

Thanks for posting about the MediaWiki translate extension: https://www.mediawiki.org/wiki/MLEB .

No developers read the Forum so if you wish to promote this extension please subscribe and post to audacity-translation.

One of the problems with "simple" Wiki translation systems (that seems to be shared by translatewiki) is that the sidebar navigation always takes you back into English. I suspect a lot more needs to be done to set up a family of Wikis on localised subdomains to make this work.

Audacity does not host its Wiki (or any audacityteam.org subdomains) on SourceForge.

Thanks,

Gale

[Beluga]

There was no developer support for moving to Transifex so it won't happen.

But was there developer opposition? It looks like you are the one doing the commits from what I can tell browsing the list archives, so I would think your opinion has some impact?

Thanks for posting about the MediaWiki translate extension: https://www.mediawiki.org/wiki/MLEB .

No developers read the Forum so if you wish to promote this extension please subscribe and post to audacity-translation.

I'm promoting Transifex foremost, because the project already exists and thus does not require any installation effort or planning from the Audacity wiki maintainer.

Anyways, let this be a reminder for people wanting to use the unofficial Transifex: don't forget to monitor what goes on outside of Transifex!
Useful links:
http://sourceforge.net/mailarchive/foru ... ranslation
http://code.google.com/p/audacity/sourc ... unk/locale
http://code.google.com/p/audacity/sourc ... ocs/locale

[Gale Andrews]

There was no developer support for moving to Transifex so it won't happen.

But was there developer opposition? It looks like you are the one doing the commits from what I can tell browsing the list archives, so I would think your opinion has some impact?

No developer comment usually implies opposition, at least in the sense that they are not motivated to take on the work involved or research into what is needed.

My comment was (and still is) that Transifex looked one of the better alternative systems, but I am not a translator, and there was not universal support for it even amongst the translators. As long as we don't drift back to the situation we had at times in the past where submitted PO files could be left uncommitted for weeks, perhaps the status quo is simpler (and safer, in case Transifex's "business model" collapses)?

Remind me why Transifex is better for translators and maintainers (given the developers probably want to retain hold over committed files).

I'm promoting Transifex foremost, because the project already exists and thus does not require any installation effort or planning from the Audacity wiki maintainer.

Is it not a change in system if commits are done through a Transifex "pull"? How would I check the PO files actually compile without errors before committing them?

One of the translators already posts PO files via a Transifex link that requires me to log in to Transifex. Someone else committing might object to that, but what are the benefits to the translator of preparing files on Transifex?


Gale

[Beluga]

There was no developer support for moving to Transifex so it won't happen.

But was there developer opposition? It looks like you are the one doing the commits from what I can tell browsing the list archives, so I would think your opinion has some impact?

No developer comment usually implies opposition, at least in the sense that they are not motivated to take on the work involved or research into what is needed.

My comment was (and still is) that Transifex looked one of the better alternative systems, but I am not a translator, and there was not universal support for it even amongst the translators. As long as we don't drift back to the situation we had at times in the past where submitted PO files could be left uncommitted for weeks, perhaps the status quo is simpler (and safer, in case Transifex's "business model" collapses)?

Remind me why Transifex is better for translators and maintainers (given the developers probably want to retain hold over committed files).

I'm promoting Transifex foremost, because the project already exists and thus does not require any installation effort or planning from the Audacity wiki maintainer.

Is it not a change in system if commits are done through a Transifex "pull"? How would I check the PO files actually compile without errors before committing them?

One of the translators already posts PO files via a Transifex link that requires me to log in to Transifex. Someone else committing might object to that, but what are the benefits to the translator of preparing files on Transifex?

Gale

As can be deduced from my view of "use Transifex now, switch to anything we want later", I see Transifex collapsing as a non-issue. We have zero effort invested in Transifex (no installing of software etc.). We will have no files "trapped in the cloud" as they will be pulled regularly and I would not think Transifex would close down out of the blue with no option to recover your files. Transifex began as a GSoC project for Fedora, so it has strong roots in open source.

Commits are not done through tx pull. It is just a simple way for you to get all the updated files to your computer. Then they can be checked.

Transifex is good for translators, because it is transparent: you see what your team members are working on without having to necessarily send them a message asking what they've been up to. Again: MediaWiki translate is even more transparent in this regard. No more duplicate work due to translators being unaware of each other. The barrier of entry is also very low for new translators. Very easy to jump in and test the waters and more experienced users are right there, you can message them inside Transifex.

Maybe there should be a direct question on the mailing list: does anyone oppose Transifex?

[Gale Andrews]

Maybe there should be a direct question on the mailing list: does anyone oppose Transifex?

No response can still imply opposition rather than just apathy.

No-one is stopping you posting on the mailing list and making your points above about the benefits to translators.

Do people on Audacity Team even need to use tx pull? What would happen if we said - no you have to decide when the .po files are ready and send them to (or advise a download link to) the mailing list as now? Transifex is then irrelevant to the developers. If translators of some locales find it easier to work that way rather than liaise on the list or by private e-mails, that is up to them.


Gale

[Beluga]

Do people on Audacity Team even need to use tx pull? What would happen if we said - no you have to decide when the .po files are ready and send them to (or advise a download link to) the mailing list as now? Transifex is then irrelevant to the developers. If translators of some locales find it easier to work that way rather than liaise on the list or by private e-mails, that is up to them.

Yes, we can continue with the current "diasporic" system, but then we will not use the full potential of Transifex as a project management tool, saving time and making everyone's work easier.

I don't want to pressure you with this and I am certainly not a Transifex fanboy, but I invite you to PM me your username and I can make you a maintainer and give you a little feature tour, even on Skype or something. If we chat, we can look at other systems in detail, too.

[Gale Andrews]

Yes, we can continue with the current "diasporic" system, but then we will not use the full potential of Transifex as a project management tool, saving time and making everyone's work easier.

Given some translators are against or neutral, that only leaves possible benefits to Audacity Team.

What do you see as the advantages to Audacity Team of each of the different degrees of integrating the translation effort into Transifex?


Gale

[Beluga]

Given some translators are against or neutral, that only leaves possible benefits to Audacity Team.

What do you see as the advantages to Audacity Team of each of the different degrees of integrating the translation effort into Transifex?

I fail to grasp why a speculated opposing stance of some individuals would mean no benefits to any translators. The unofficial project already has 22 language teams, whose members are quite obviously seeing benefits - otherwise they wouldn't have joined. Why couldn't an opposing minority continue using email? I will personally never use a mailing list and others are free to not join Transifex. Besides, the responses in the mailing list discussion containing alternative platform suggestions were apparently inspired by the false assumption that Transifex is not GPL.

Of the alternatives suggested Pootle is the strongest, I think (compared to Launchpad and GlotPress). Pootle setup effort might be avoided, if Audacity was accepted in the Locamotion Project.

Sure, there are a lot of tools to choose from, but who will do the work of evaluating them and setting up an installation? If we focus on Transifex first for a period of time, people are in a better position to compare the different platforms and express their wants and needs based on real experience.

I have seen opposition to Transifex in the Joomla! CMS translator community, but that is strictly related to the Open Translators "free for all" model, which is not how the current Audacity unofficial project works.

Advantages to the language committer I have already described in my previous posts. I don't see other degrees than using it as currently vs. making it the main official platform.

I am the language teams manager for RetroShare. One of the devs does the commits. You can read the RS translation wiki article and see, how I've edited it to reflect our current model. Notice how Transifex is labeled as recommended, but not enforced..

[CroatianFan]

Hello!

Ten days ago a new Croatian translation of Audacity was finished. Translator Martin B. did a massive job, but - unfortunately - his translation needs complete revision because of many lexical and orthographical problems. I decided to do the job in the next few months on Transifex. Then, I will contact the developers.

CroatianFan