Proposal for SVN and Transifex symbiosis

[gyuris]

Our goal is to provide a clear and easy to handle SVN and Transifex symbiosis:

• clear for translators,
• easy to handle for us and for language coordinators.

I'm not satisfied with the current situation. We have many languages and some problematic languages:

• de, de_1901, de_CH: There is no language team, no language coordinator on Transifex. It's OK.
• da_DK, en_AU: There is a language team with only one member, namely the language coordinator. It's OK.
• en_GB: There is a language team with only one member, namely the language coordinator. But there are pending join requests.
• it: There is a language team with language coordinator, but there are other translators in the team too.
• fr: There is a language team with many members and many pending join requests, but the language coordinator is not the official translator. He is not present on Transifex.

It's pretty chaos.

Solutions

1. Delete directly maintained languages from Transifex and do not push they any more on Transifex. These translators do not have to deal with Transifex. There would be no language teams for these languages. If sometimes someone request these languages on Transifex project admins can reject these requests.

2. Push directly maintained languages to Transifex as now happens (and don't pull them). But what is missing: To show for other translators that we don't need help for these languages we should push them always when they are changed in SVN and keep them in 100% state in Transifex and manually mark them reviewed in 100% percent. These would be the correct state. We need language coordinators on Transifex only for this 2 task: mark translations reviewed and reject join requests. But in fact, project admins can mark translations revived and reject join request, so we don't need project coordinators in this case too. It would be easier without language coordinators for directly maintained languages.

3. We need language coordinators and language teams for directly maintained languages just in case when they want mix SVN and Transifex in they workflow. What it means mixing? If official translator for directly maintained language want full control but he need help he can sign up for Transifex, can build a team and we nominate him as language coordinator. When Scribus developers push source files on Transifex ha can/should mark all translated strings reviewed so the translators can deal only with new, untranslated strings. He has the right to review translators work. If one translator or the language coordinator want to translate manually or with other tool, he can download the source, work on it and the upload it back. Coordinator can download source from Transifex and add to SVN. For this case me must create a script to push translations automatically to Transifex on SVN commit.

Evaluation

The 1st case is simple. It's clear and it doesn't require a lot of work. I like it.

The 2nd case is simple. It shows more for translators. I recommend to transform current situation to that state.

Third case is not to simple, but has a lot of possibilities.

Request

Scribus devs, please comment and decide what to do. It would be great to clear current chaos.

[luzpaz]

CC @MrB74

[FirasH]

As a translator here are my thoughts (generally speaking):

1) The old style of the translation process is not suitable for team coordination We have to deal with our local copies of .ts files and push them to SVN. Plus we have to carry with us a copy of the .ts file if working on more machines. That does not enable other translators of the same language to work simultaneously not knowing what is and what is not completed.

2) The old style of the translation process is more direct Using Qt Linguist you see side by side source and UI mockups (where user interface is designed with .ui) or where not possible the source code (handy for fixing duplicated strings, etc). I really like that idea and personally that is what did not make me choose Transifex (but I am willing to improve the team workflow at the same time).

3) On Transifex translators can create a Glossary Inconsistencies are the easiest mistake that a translator can do, so that is a plus of Transifex and I can work on creating a Glossary for Italian language.

4) On Transifex language coordinators can review strings I personally do not trust new translators, not because I think I am better, but because when you are new to a project you need some time to settle in. I made mistakes in the translations of 1.5.x and 1 week later I changed them back, nothing impossible, but if I had someone telling me that was wrong I would have saved a lot of time!

Transifex is a step forward to make things easy for not technical contributors and allow more people to be part of it and that is what we want.

If I had to choose a workflow it would be as follows: 1) Move all the translation process to Transifex 2) Translations source strings move from Transifex to SVN 3) If a translator wants to use the old style of the translation process (like I do) they can download the translation file from Transifex, work on it and upload it back to Transifex as often as possible.

[aoloe]

please, (re-)evaluate using a free alternative, before moving the official translation workflow to transifex.

[luzpaz]

@aoloe we've put much work in to this approach. We have 58 languages that are potentially being translated. Almost 150 volunteers signed up to said languages. Other OSS are using Transifex as well. etc..etc..

If someone wants to improve per your suggestion.. they can feel free to try independently of this effort. Momentum in Scribus is a delicate thing. I suggest not to hamper momentum in this direction. Thanks.

[gyuris]

@aoloe Zanata is an open source alternative for Transifex, but it currently doesn't support .ts format. Zanata 4.0 will support Qt's .ts format.

And some statistics: I'm Hungarian translator. In Zanata there are only 19 registered Hungarian translator.

So, are there any open source alternative for Transifex?