(In reply to comment #0)

The reasons for using Transifex.net are both historical and practical. Earlier when we were not using GNOME infrastructure (git.gnome.org, bugzilla.gnome.org, projects.gnome.org), Transifex.net was an obvious choice. Now some of our language translators who started contributing through Transifex.net happen to be GNOME translators also. However some of these GNOME translators, who used to submit through Transifex.net, still prefer to use Transifex because they find it easier to use than Damned Lies.

Also, you might have noticed that GNOME translators can directly push changes to our git.gnome.org repository while those using Transifex.net can not. Simply because Transifex.net does not have write access to git.gnome.org. Therefore in cases of conflicts (we have not had any till now) I plan to give preference to the submissions from Damned Lies.

I hope I do not have to make an exclusive choice between one tool or another. After all I am not a translator. I would rather have the translators work out the best solution.

Thanks for your explanations. I understand the historical context. But it is still not acceptable to use both tools. Even if you have control on files submitted through transifex, this situation generates duplicated work when two people are simultaneously translating a file in the same language.

However, I will also ask for feedback on gnome-i18n, so as I'm not the only judge of the situation :-)

I agree with Claude. Two translation platforms for translators are something like two source code repositories for developers. It is doable for small amount of workload, but when the workload is getting bigger it can became a nightmare for both developers and translators.

I'm not sure I follow the reasons why this might cause problems to our standard workflow in GNOME. A person can use both the CLI and Transifex to submit the file directly to the VCS, so there's only one upstream repo (the files are always synced in Tx).

The issue about people working simultaneously is valid but easily solvable by following the standard GNOME workflow. A person is required to "take" the file in DL and just translate the file in his favorite tool and commit it. In this case, Transifex takes the role of the PO editor and commit script.

Since GNOME uses a distributed VCS, it's a pity not to leverage its full powers and allow developers to grow their translator base.

Is is possible to block those translations that come from transifex when there is already a translation team working on the module? I mean, if there is a team in Damned Lies translating the module, then you could print a message in transifex so interested new translators know wheter they could use transifex or they should contact the l10n GNOME team.

In any case, I also think duplicated work is a pity and should not be accepted, plus, merging translations from translators outside l10n Teams is usually a pain, since they do not follow the same style guide.

(In reply to comment #4)
(...)
> The issue about people working simultaneously is valid but easily solvable by
> following the standard GNOME workflow. A person is required to "take" the file
> in DL and just translate the file in his favorite tool and commit it. In this
> case, Transifex takes the role of the PO editor and commit script.

Sorry, but this does not prevent duplicated work. Anyone can still work on Transifex outside of the GTP.
This might work in the future but we would have to carefully plan DL <-> transifex relationship, where the entry point should be one platform and actions (reserve, upload, etc.) being communicated between platforms. But we are far from it currently.

> Since GNOME uses a distributed VCS, it's a pity not to leverage its full powers
> and allow developers to grow their translator base.

It's not a matter of VCS or translator base, it's a matter of workflow, and we simply cannot mix two different workflows hoping that they will magically work together. (don't take it harsh)

The thing is that if solang wants to be a real GNOME module, it should definitely respect the standard approach to the i18n infrastructure, that is giving the GTP the l10n exclusivity. As far as I can tell, every other module being incorporated into the GNOME infrastructure has done this, so why solang should be different, after all?

Moreover, the current transifex.net can't support translation team work flow, or not in a sensible way, cf. [1], so there can hardly be established any communication canal between the transifex.net and the GTP members. Now, virtually anybody can sign up at transifex.net and start translating solang, regardless of any existing l10n guidelines, newcomer isn't even notified of the fact that solang has actually two different i18n infrastructures.

[1] https://transifex.net/projects/p/solang/teams/

I've temporarily deactivated stats for solang on l10n.gnome.org, until this issue is resolved (that is *one* tool is chosen).

Thanks for all your inputs. We will continue to use transifex.net for accepting translations. Many thanks to the GNOME localization community and the translators for their contributions.

So please remove it from Gnome's git repository, Gnome modules have to use Gnome's l10n infrastructure, having the code but not the translation hosted by Gnome will just cause confusion and is not helping any one.

(In reply to comment #10)
> So please remove it from Gnome's git repository,

Now hang on a bit.

> Gnome modules have to use
> Gnome's l10n infrastructure, having the code but not the translation hosted by
> Gnome will just cause confusion and is not helping any one.

Where is the written policy about this?

Just being hosted on git.gnome.org and using other bits of GNOME infrastructure does not make a program an official GNOME module. Solang is not an official GNOME module.

I deeply believe that empowering people (developers, translators, everyone) to contribute as best they can is key to making GNOME succeed. Let's work together to make sure this happens, bring down any walls obstructing the work and separating the community, and help dissolve any confusion. =)

Maybe a wiki page listing the git.gnome.org projects with PO files which aren't being served from DL would help in the (rare) case someone is going through all git.gnome.org to find projects to translate, instead of l10n.gnome.org. A README.translations inside po/ would also help.

For the record: http://mail.gnome.org/archives/gnome-i18n/2010-February/msg00198.html