Heya,
What is the current policy for incorporating translations from launchpad to current source of Roundcube?
I am asking this, because I've noticed that some of the translations from launchpad (e.g: Slovenian password plugin translation) do not come into the sources of Roundcube and users should take care of that (http://trac.roundcube.net/wiki/Doc_Plugins#Internationalization). Are there any plans to make this process easier on the users?
Cheers, Jernej
Jernej Porenta wrote:
Heya,
What is the current policy for incorporating translations from launchpad to current source of Roundcube?
I am asking this, because I've noticed that some of the translations from launchpad (e.g: Slovenian password plugin translation) do not come into the sources of Roundcube and users should take care of that (http://trac.roundcube.net/wiki/Doc_Plugins#Internationalization). Are there any plans to make this process easier on the users?
For plugins which reside in our own git repository the translations will be pulled from launchpad and distributed with the official Roundcube releases. There's no automated process set up doing this so the git repository might lag behind the status of the launchpad translation system.
Plugin developers also have the possibility to submit their translations to the launchpad system. The process is described on the page you mentioned above. The "planner" plugin for example does it that way.
I know, that the workflow isn't perfect but for now we don't have a better solution than taking merge requests from your Bazaar branches in order to list your plugins in our translation section of launchpad. What I initially had in mind was to give plugin developers direct access to the main Bazaar branch on launchpad but I so far failed to find out how that can be done on the launchpad system.
~Thomas
Hi
2012/7/20 Thomas Bruederli thomas@roundcube.net:
I know, that the workflow isn't perfect but for now we don't have a better solution than taking merge requests from your Bazaar branches in order to
<cut>
Thomas, i think that this discussion can be extended to core too. The fact that all translations for RC in Launchapad to be open is a concern's motive. IMHO, is complicated maintain a good quality in translation process if any person can enter there and rewrite what wish.
I remember that I rewrote a lot of translations without sync (or style pattern) with other translations, what can put down the software quality as an all. I revised all translations that i use (between them, all in Rosali repository), and I try to maintain a consistency for all.
In other hand, we have focus with a front and not in other? Only maintaining opened we can receive more contributions, and closing, we will lost this contribution? I think that no. In all projects, i did the translation based in a PO file, I sent to maintainer and, at final, the translated product is there.
My two cents about this translation policy.
Bests, Claudio
Am 22.07.2012 16:54, schrieb Claudio Filho:
Thomas, i think that this discussion can be extended to core too. The fact that all translations for RC in Launchapad to be open is a concern's motive. IMHO, is complicated maintain a good quality in translation process if any person can enter there and rewrite what wish.
I remember that I rewrote a lot of translations without sync (or style pattern) with other translations, what can put down the software quality as an all. I revised all translations that i use (between them, all in Rosali repository), and I try to maintain a consistency for all.
I have a very simple automated process. I've written a Roundcube Plugin. When a trusted translator logs into Roundcube he is able to create or edit lanaguage packs for languages associated to the translator. The plugin simply writes the new or edited language file into my SVN folder and they get published with next release.
It works with file_put_contents. I know this won't work for you, but I think, it could be done with fsockopen or cURL as well. Unfortunately I'm not familiar with the SVN protocol, but I could support with code framework.