[xwiki-devs] Selecting a tool to manage localization
Hi team, I wrore a report about the different localization strategies we could have for XWiki comparing: - a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc... Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us. Let's discuss. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Oct 31, 2008, at 2:05 AM, Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
What would be the process of committing the modified translations to our SVN with launchpad.net? Is launchpad.net customizable easily to modify that? Some ideas of how we could integrate it with our SVN: 1) Using JIRA. Note: What they do in maven land is the following (for publishing artifacts to the central repo): * A JIRA project. * Then they have a script that reads the attached files directly from JIRA and apply them So we could have something like: * Automatically create a jira issue with a patch attached * Have a tool that reads the jira issues and apply the patches (btw this could be generic to any type of jira patches) 2) Another solution would be to use Git and merge Git branches into our svn trunk. This is very easy to do with Git. The downside is that our contributors will not be technical so Git would be too complex for them. 3) Another solution would be to have the svn commit be made directly from the web application (by a committer). This means specifying the svn password when committing for ex. 4) Another solution would to have a special SVN server or project that has no passwords for committing and it's the users who commit directly to it using a username they provide. This would send a diff email to the list (as normal) and committers would do the review and commit the changes by doing a merge. Thanks -Vincent
Vincent Massol wrote:
On Oct 31, 2008, at 2:05 AM, Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
What would be the process of committing the modified translations to our SVN with launchpad.net? Is launchpad.net customizable easily to modify that?
I think we would need some tools on our end to import/export data from launchpad.net. Launchpad uses gettext translations files (.po) which can be converted from/to java resources with some python tools. However the format is not that complex and we could easily write our own converter. For me the process is the same for launchpad.net or for an XWiki application. We import regularly the english language file to launchpad. We import once the other translations. Then we can have our build process either pick up automatically the currently validated translations files or we have a manual export and commit of the work done on launchpad. It would be the same for an XWiki based application. In this method the application becomes the authoritative source for all translations and direct commits to the translations files should be forbidden except the english version. Ludovic
Some ideas of how we could integrate it with our SVN:
1) Using JIRA.
Note: What they do in maven land is the following (for publishing artifacts to the central repo): * A JIRA project. * Then they have a script that reads the attached files directly from JIRA and apply them
So we could have something like: * Automatically create a jira issue with a patch attached * Have a tool that reads the jira issues and apply the patches (btw this could be generic to any type of jira patches)
2) Another solution would be to use Git and merge Git branches into our svn trunk. This is very easy to do with Git. The downside is that our contributors will not be technical so Git would be too complex for them.
3) Another solution would be to have the svn commit be made directly from the web application (by a committer). This means specifying the svn password when committing for ex.
4) Another solution would to have a special SVN server or project that has no passwords for committing and it's the users who commit directly to it using a username they provide. This would send a diff email to the list (as normal) and committers would do the review and commit the changes by doing a merge.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi Ludo, I have mentioned your work on #launchpad at irc.freenode.net and the launchpad team is interested in helping out. I have an "appointment" to talk to danilos in about 2h so if you or Vincent are interested maybe that would be a good opportunity to learn more. I will report back otherwise. Some of the things you may want to think about: - There is actually already an xwiki project in launchpad that I created a long while back, danilos suggested that translation should go through there https://edge.launchpad.net/xwiki - There is a way to group projects together in launchpad which would take care of translations for the different components, applications etc - There is an api initiative, currently in beta, which could provide an elegant way of meeting all of your requirements through mixing a launchpad backend with a lightweight xwiki app. The api could help out in automating SVN sync although it currently doesn't focus on translation features but maybe its not too hard to put some features like that on the roadmap. https://help.launchpad.net/API To my knowledge launchpad is going to be released as open source, but is not there yet. Luis 2008/10/31 Ludovic Dubost <[email protected]>:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Luis Arias +33 6 14 20 87 93 skype : kaaloo
Luis Arias wrote:
Hi Ludo,
I have mentioned your work on #launchpad at irc.freenode.net and the launchpad team is interested in helping out. I have an "appointment" to talk to danilos in about 2h so if you or Vincent are interested maybe that would be a good opportunity to learn more. I will report back otherwise.
Some of the things you may want to think about:
- There is actually already an xwiki project in launchpad that I created a long while back, danilos suggested that translation should go through there
Let's use that one instead of the one I created.
- There is a way to group projects together in launchpad which would take care of translations for the different components, applications etc - There is an api initiative, currently in beta, which could provide an elegant way of meeting all of your requirements through mixing a launchpad backend with a lightweight xwiki app. The api could help out in automating SVN sync although it currently doesn't focus on translation features but maybe its not too hard to put some features like that on the roadmap.
I'll check the API. We need to have sufficient access the export that data programmatically if we want to import the english versions easily and gather back the translations result easily.
To my knowledge launchpad is going to be released as open source, but is not there yet.
That could be a showstopper if we want to make sure we keep control.
Luis
2008/10/31 Ludovic Dubost <[email protected]>:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Dare I suggest to add the fundamental requirement to support re- organization of resource-bundles? I am not sure I saw this explicitly in this list but maybe you can confirm it's there. Basically, the need is as simple as that: - version x+1 of the software is done, there's a few changes in the resources, some parts moved to other bundles - translator is contacted to work on the translation and the merge tool applies the developer bundle organization (that includes all the moves) to his (or his language) previous files - he can now work on the reorganized bundles without needing to port manually the copies I've done a command-line-tool that does just that... but I think you want a whole lot more in the description there. paul Le 31-oct.-08 à 02:05, Ludovic Dubost a écrit :
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Paul Libbrecht wrote:
Dare I suggest to add the fundamental requirement to support re-organization of resource-bundles? I am not sure I saw this explicitly in this list but maybe you can confirm it's there.
Basically, the need is as simple as that: - version x+1 of the software is done, there's a few changes in the resources, some parts moved to other bundles - translator is contacted to work on the translation and the merge tool applies the developer bundle organization (that includes all the moves) to his (or his language) previous files - he can now work on the reorganized bundles without needing to port manually the copies
I've done a command-line-tool that does just that... but I think you want a whole lot more in the description there.
paul
I think this is taken into account by the tool. When versions x was already translated and validated, the tool says translations are up to date. When version x+1 is done, the main language files are reloaded in the tool. At this point, the tool will point out: - all empty translations (new strings) - all keys that have the main language text that has changed from the previous version The translator can work on these on the online site. In the online tool approach, the online tool is the master for all translations. Nobody shoud work directly on translations bundles. Ludovic
Le 31-oct.-08 à 02:05, Ludovic Dubost a écrit :
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
------------------------------------------------------------------------
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Careful, I really meant give flexibility for developers to move around sections of bundles... of course without translators re-translating. That doesn't seem to be taken care of. One bad experience which made us completely disqualify 99translations which, I think, is similar to most only tools is the absence of sections and comments... e.g. "these phrases appear in this UI". This is really crucial! paul Le 04-nov.-08 à 01:23, Ludovic Dubost a écrit :
I think this is taken into account by the tool. When versions x was already translated and validated, the tool says translations are up to date. When version x+1 is done, the main language files are reloaded in the tool. At this point, the tool will point out:
- all empty translations (new strings) - all keys that have the main language text that has changed from the previous version
The translator can work on these on the online site.
In the online tool approach, the online tool is the master for all translations. Nobody shoud work directly on translations bundles.
You mean a developer renaming a key ? Well the only way for this to be handled by the tool would be to have the developer declare the key name is being changed. This could be done but would need to be done in the tool, not in the initial bundle. Ludovic Paul Libbrecht wrote:
Careful,
I really meant give flexibility for developers to move around sections of bundles... of course without translators re-translating. That doesn't seem to be taken care of.
One bad experience which made us completely disqualify 99translations which, I think, is similar to most only tools is the absence of sections and comments... e.g. "these phrases appear in this UI". This is really crucial!
paul
Le 04-nov.-08 à 01:23, Ludovic Dubost a écrit :
I think this is taken into account by the tool. When versions x was already translated and validated, the tool says translations are up to date. When version x+1 is done, the main language files are reloaded in the tool. At this point, the tool will point out:
- all empty translations (new strings) - all keys that have the main language text that has changed from the previous version
The translator can work on these on the online site.
In the online tool approach, the online tool is the master for all translations. Nobody shoud work directly on translations bundles.
------------------------------------------------------------------------
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Le 04-nov.-08 à 02:08, Ludovic Dubost a écrit :
You mean a developer renaming a key ?
I mean the developer *moving the key*. For example he could move it to another file, or simply to another section of the source. For the developer renaming a key, this is more difficult as you point out, but it may be worth that such an evolution tool has "automated suggestion coming from other parts" (but "please validate that suggestion you translator"). paul
Well the only way for this to be handled by the tool would be to have the developer declare the key name is being changed. This could be done but would need to be done in the tool, not in the initial bundle.
I think we can achieve both renaming and moving keys if we do this in the tool and not directly in SVN files. The current level of information given by the translations files won't currently allow the tool to detect this from the translations files unless we extend the translation file spec and add some info like that in the files. I've been thinking we could make the translation tool the master for the main language file also. Keys would have to be added there. In this case we can also rename and move and then have a commit system or have the build system pick up the files directly from there. Ludovic Paul Libbrecht wrote:
Le 04-nov.-08 à 02:08, Ludovic Dubost a écrit :
You mean a developer renaming a key ?
I mean the developer *moving the key*. For example he could move it to another file, or simply to another section of the source.
For the developer renaming a key, this is more difficult as you point out, but it may be worth that such an evolution tool has "automated suggestion coming from other parts" (but "please validate that suggestion you translator").
paul
Well the only way for this to be handled by the tool would be to have the developer declare the key name is being changed. This could be done but would need to be done in the tool, not in the initial bundle.
------------------------------------------------------------------------
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Hi, I think we need to move forward and get to a decision on our approach. I've currently not been very convinced on the launchpad approach given that it seems overly complex to get our translations loaded in their system. The french translations I've been trying to load are blocked for review (see https://translations.launchpad.net/xwiki/+imports ). Also I don't see clearly where to get the source code for launchpad to have our own install if we wanted, and how complex it would be given that launchpad has many other features unrelated to translations. On the other hand, I've improved the speed of the translation app on http://l10n.myxwiki.org using counting caches and it seems to work quite well. So I would like to launch a vote to go with the XWiki translation application approach and move it to it's own wiki on l10n.xwiki.org. We also need this wiki to be UTF-8 in order to support translations in all languages. Here is my +1 for using l10n.myxwiki.org Ludovic Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic Dubost wrote:
Hi,
I think we need to move forward and get to a decision on our approach.
I've currently not been very convinced on the launchpad approach given that it seems overly complex to get our translations loaded in their system. The french translations I've been trying to load are blocked for review (see https://translations.launchpad.net/xwiki/+imports ). Also I don't see clearly where to get the source code for launchpad to have our own install if we wanted, and how complex it would be given that launchpad has many other features unrelated to translations.
On the other hand, I've improved the speed of the translation app on http://l10n.myxwiki.org using counting caches and it seems to work quite well.
So I would like to launch a vote to go with the XWiki translation application approach and move it to it's own wiki on l10n.xwiki.org. We also need this wiki to be UTF-8 in order to support translations in all languages.
Here is my +1 for using l10n.myxwiki.org
+0
Ludovic
Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Ludovic Dubost wrote:
Hi,
I think we need to move forward and get to a decision on our approach.
I've currently not been very convinced on the launchpad approach given that it seems overly complex to get our translations loaded in their system. The french translations I've been trying to load are blocked for review (see https://translations.launchpad.net/xwiki/+imports ). Also I don't see clearly where to get the source code for launchpad to have our own install if we wanted, and how complex it would be given that launchpad has many other features unrelated to translations.
On the other hand, I've improved the speed of the translation app on http://l10n.myxwiki.org using counting caches and it seems to work quite well.
So I would like to launch a vote to go with the XWiki translation application approach and move it to it's own wiki on l10n.xwiki.org. We also need this wiki to be UTF-8 in order to support translations in all languages.
Here is my +1 for using l10n.myxwiki.org
+1 from me, too
Ludovic
Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Any -1 votes ? Or should we proceed on setting up our own l10n.xwiki.org tool ? Ludovic Ludovic Dubost wrote:
Hi,
I think we need to move forward and get to a decision on our approach.
I've currently not been very convinced on the launchpad approach given that it seems overly complex to get our translations loaded in their system. The french translations I've been trying to load are blocked for review (see https://translations.launchpad.net/xwiki/+imports ). Also I don't see clearly where to get the source code for launchpad to have our own install if we wanted, and how complex it would be given that launchpad has many other features unrelated to translations.
On the other hand, I've improved the speed of the translation app on http://l10n.myxwiki.org using counting caches and it seems to work quite well.
So I would like to launch a vote to go with the XWiki translation application approach and move it to it's own wiki on l10n.xwiki.org. We also need this wiki to be UTF-8 in order to support translations in all languages.
Here is my +1 for using l10n.myxwiki.org
Ludovic
Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
No -1 until now. Ludovic Dubost wrote:
Any -1 votes ? Or should we proceed on setting up our own l10n.xwiki.org tool ?
Ludovic
Ludovic Dubost wrote:
Hi,
I think we need to move forward and get to a decision on our approach.
I've currently not been very convinced on the launchpad approach given that it seems overly complex to get our translations loaded in their system. The french translations I've been trying to load are blocked for review (see https://translations.launchpad.net/xwiki/+imports ). Also I don't see clearly where to get the source code for launchpad to have our own install if we wanted, and how complex it would be given that launchpad has many other features unrelated to translations.
On the other hand, I've improved the speed of the translation app on http://l10n.myxwiki.org using counting caches and it seems to work quite well.
So I would like to launch a vote to go with the XWiki translation application approach and move it to it's own wiki on l10n.xwiki.org. We also need this wiki to be UTF-8 in order to support translations in all languages.
Here is my +1 for using l10n.myxwiki.org
Ludovic
Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
-- Sergiu Dumitriu http://purl.org/net/sergiu/
I've not thought enough about this (I wanted to do it but got swamped with other stuff) so I'm +0 on it. One thing (maybe it was discussed): it would be nice if the solution was able to change the UI directly on the wiki it's defined so that the person who fills translations can see them in action by navigation to the wiki pages. That would help a lot especially by choosing text that fits in the target location. My only worry is that I've seen that the tool requires to be the master which means (I think) that we cannot edit SVN files any more. We would need to find a way to make this error-proof somehow (special svn rights on some files/dirs, synchronization, Git branches, etc). This is probably not too urgent and we should probably see how it works in action first. Thanks -Vincent On Nov 10, 2008, at 1:04 AM, Ludovic Dubost wrote:
Any -1 votes ? Or should we proceed on setting up our own l10n.xwiki.org tool ?
Ludovic
Ludovic Dubost wrote:
Hi,
I think we need to move forward and get to a decision on our approach.
I've currently not been very convinced on the launchpad approach given that it seems overly complex to get our translations loaded in their system. The french translations I've been trying to load are blocked for review (see https://translations.launchpad.net/xwiki/+imports ). Also I don't see clearly where to get the source code for launchpad to have our own install if we wanted, and how complex it would be given that launchpad has many other features unrelated to translations.
On the other hand, I've improved the speed of the translation app on http://l10n.myxwiki.org using counting caches and it seems to work quite well.
So I would like to launch a vote to go with the XWiki translation application approach and move it to it's own wiki on l10n.xwiki.org. We also need this wiki to be UTF-8 in order to support translations in all languages.
Here is my +1 for using l10n.myxwiki.org
Ludovic
Ludovic Dubost wrote:
Hi team,
I wrore a report about the different localization strategies we could have for XWiki comparing:
- a simple tool Jean-Vincent wrote - an L10N app I started to build - using launchpad.net
http://dev.xwiki.org/xwiki/bin/view/Drafts/Selecting+a+tool+for+managing+Loc...
Please review and add requirements if you see requirements that have not been listed. I think we need to look at the applications and evaluate them in more details, especially to see of launchpad.net could work for us.
Let's discuss.
Ludovic
participants (7)
-
Ludovic Dubost -
Ludovic Dubost -
Luis Arias -
Marius Dumitru Florea -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol