Hello,
How about we integrate the current .po files in the online service of transifex.net/ to ease the contribution of “non geeks” translators?
This service provides a web form to fill the required translations. It seems to be free and to be compatible with most CSV systems, wich launchpad (my favorite in the area) is not.
B.
Yes good idea. Can you handle it?
-G
Done.
Please have a look at transifex.net/projects/p/synfig/c/master/
The translations made there can either
I just sent you the translation update I made to test the platform to your gmail account. that’s the kind of result you should expect from option 1. If this is your prefered solution please register an account on transifex and tell me your username to be added as an admin of this synfig translation tool and get mail notifications automatically.
If you prefer the second option please add “transifex” user to the git commiters in sourceforge (following doc at transifex.net/help/developer/sourceforge/, close to bottom of the page).
Let me know if you like this idea, and want to use the plaftorm. I would then promote the platform on the wiki for translators. If you don’t wanna use it no problem, I’d then get rid of the whole thing.
B.
I’ve registered to Transifex as genete.
I would prefer the first option (email) and if later I cannot handle the translation flow we can change later to direct git writing. At first stage I don’t like the idea of open a security hole by giving to transfix the option to write in the git repository to anyone.
At this point it would be good that someone else, that handles well to build the source code and have a working building environment, offers him/herself to handle the application of the translation patches. It is not so much work but always any help is welcome.
-G
Another “security” scheme could be set up:
Transifex allows for “translations groups” to restrict the access to editors: only users accepted by the admin would be allowed to submit changes in the online tool for a given language, others would need to apply first (eventually providing for a sample translation if we so wish).
This is to me a small obstacle to having the group of translators grow quickly, but would (I guess) be enough to allow for “not too dangerous” the transifex-git synchronization.
If you rather want to go for this alternative tell me.
On a side note: the transifex sf.net user would indeed have access to the whole git repository, but only the po/* files are exposed to the users of the translation platform… so risk is limited.
… and I’m not tech enough to apply for synzing this, sorry.
it is not so easy to control the quality of online translation. as we know, doing software ui translationjust reading the po file is not a good way. maybe we have to setup some rules for it.
Great website! I’ve registered as “nikitakit”, though I dunno if I’ll actually be doing translations.
As for security, we can tell transifex to track/commit translations to a separate branch. Our administrators can confirm the quality of translations before merging them into the master branch. I think that the worst things that can happen are intentional vandalism of the translations or a bad commit that messes up some source files. These can be reverted given that the server and all of the individual devs have a version history for the project.
For the sake of completeness, I’ll also broach the idea of setting up a separate repository for transifex. Git makes multiple repositories relatively easy to manage, so the major problem here will, of course, be hosting. If the repository were to contain just translations, as opposed to being a complete clone, then hosting would be easy (the size of the translations is around 3 MB). Zelgadis seems to have used “git subtree” for Morevna Project – maybe he can comment whether it is a viable option. Of course, it may be that such a configuration would be too difficult to set up and maintain.
Translations are not possible for the developers (in general) to check its full validity even looking the po file, neither applying the language in your computer, unless you have a good multilanguage knowledge (specially for non Latin languages). So when I apply a new translation to the git branch I just verify that gettext hasn’t any error when processing the po file.
In general there should be one translator responsible for each language who, or take charge of the translation maintenance or take care of the quality of the translation patches.
I’m responsible for Spanish language quality. Anyone want to step in for the rest?
-G
Let me clarify my previous post. Instead of “confirming the quality” I should have said just what genete did: checking for gettext errors. As for the rest, I was thinking of how to prevent transifex from messing up the master branch (be it via bug, bad translation, or security hole) by means of using other branches or repos. I hope that makes sense.
I just ran a test on the Russian translation by unfuzzying one of the strings. (It’s a valid change). The website has not changed to reflect it since it hasn’t been approved. Here I see a slight problem: if the translator uses the online editor and doesn’t see the result of their work, they might end up translating the same strings twice. That’s why I’m making the suggestion of doing commits to a branch.
P.S. When I clicked on the “edit” button to view some translations, I accidentally locked the files. Sorry about that. They don’t unlock until you press “submit”, “cancel lock”, or the time limit expires.
transifex does it automatically (or at least I think so), and its check include checking for parameters placeholders if you use some too (of this I’m sure).
I can handle french for “intuitive check”, but cannot build synfig to test for the visuals (such as text too long for GUI)… so if you want a real check someone else please apply!
Seems an elegant solution to me: you have the comfort of seing your work taken into account as a translator, and before release devs can do a quick check & sync.
that’s the way the system works. i guess since we are not a huge crowd it should not create big issues.
B.
Applying the translation directly to master or use a branch is irrelevant in my opinion. I can make subtle vandalism in the Spanish translation and nobody would notice it. It is fair easy to modify just a letter and turn a valid word into a obscene word. 
Since Transifex checks the validity of the po file from the point of view of structure there is no way to avoid vandalism if anyone with the proper language knowledge builds the application and run it with the translated language and then checks if the translation still being fine.
As I mentioned before, the current way of work (agreed by berteh and me by email) is that I receive by email the po file and apply it to master without checking its language quality (it is what I’m doing just now with the patches at sf) If the transfiex patches grow up then we can decide if the translations will go to the master or a branch directly. In that case I think that it is needed that (like is being done in the wiki) native speakers for each language take care of the translation update from the point of view of translation quality. Also, if anyone want to have git writing for that kind of things like applying translations (prokoudine asked that right for that) just tell me.
Finally, if I receive translation patches from transifex from not known synfig users I will take extreme care to ask the last valid translator if the file is not mangled.
-G
I should ignore the Russian po patch, right?
I therefore added a short warning in the transifex page: transifex.net/projects/p/synfig/c/master/
[i]"Your contribution to these translations are sent by mail to the Synfig coders for validation.
Once reviewed they’ll be integrated in the Synfig source code and will only then be visible in the translations statistics.
Please be patient as this process may take a few days."[/i]
I don’t think so. Nikitakit?
I have something else to add:
Every time that there is a git commit, the po files needs to be updated before get translated. First because the referencing file line number where the translatable string appears can change in each commit. Second because new translations strings can be added.
According to the Translation instructions, the translator needs to do make update-po in each po folder before update the translation by modifying the corresponding po file. None but the translator can do that, and transifex is not doing it. Obviously the coder won’t do a po update for each po file every time a new commit is sent because it would be a waste of time.
I’m 99% sure that Launchpad uses an automatic system to update each po file (or whatever other translation system is used) on each commit, so the translatable files are up to date continuously. For a gettext translation system, I don’t know another way to update the po files that doesn’t involve the translator interaction.
Also for new translations, transifex system has some drawbacks. First, an unexpert translator would try to take an existing po file and translate it to his language. It is an error because he can use an old po file (without the latest translatable strings) and also it is a pain to translate (even using a po editor) a po file that it is already translated. Unless you make all the strings fuzzy with some utility from the po editor it implies much more work than following the translation instructions. Once the translator runs msginit it obtains a clean, ready to translate po file for his language. Second, add a new translation implies modify the configure.ac file that at the end needs the coder intervention.
-G
Gettext is smart enough to track most changes to the repository, except (of course) new strings. In my opinion, it would suffice to do manual updates after merging a major feature, before string freeze, and immediately before release. String freeze should give enough time to fix a few fuzzy and untranslated strings in complete translations, while for a new translation the number of out-of-date strings would be tiny compared to the entire effort. IIRC, the po template (pot) file is all that is needed to generate a new translation, and existing ones need just the po - so translators don’t need to be required to check out complete copies of the source code. Instead, a single developer could keep po’s up-to-date, modify configure.ac, etc.
As for my change, it’s valid though probably not worth a commit.
The problem is that pot files are not tracked in git repo. They are generated by gettext based on POTFILES, and the current source code and are not always the same, they depends on the source code structure.
-G
My bad, I didn’t know this. Though that does raise the question of whether they ought to be version tracked. I did a quick look-up and found that gimp and blender don’t appear to version track the pot file, while inkscape does.
Looks to me like transifex is doing a diff-like comparison between the translation and the en-GB (reference) po strings. This is were the statistics and missing string identification comes from at least… So at least if some coder makes the update-po on the en-GB it might be enough… this gotta be checked though.
I fully agree on this one, and got no alternative workflow to propose here.