31 Oct
2008
31 Oct
'08
7:59 p.m.
Vincent Massol wrote:
On Oct 31, 2008, at 2:05 AM, Ludovic Dubost wrote:
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
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+Lo…
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost