Trac i18n and Transifex
Christian Boos
This morning I discovered that the Transifex hosting site [1] had
integrated Trac as a test project [2]. As it stands, this mainly gives
us an overview of the work in progress.
I was told that there were some concerns about this, and questions about
the implications this will have for our translation process. So let's
discuss this openly here. The statistics themselves are a non-issue, as
this is merely informative and should have no consequences, other than
perhaps motivating the translators to update their translations, of
course ;-)
The real question is if it would be a good idea to allow submissions
from Transifex, what would be the pros and cons.
Personally, I think this would be a good thing, and my immediate
reaction was to wonder why the submissions were not yet activated... So
I got in touch with Dimitris Glezos (Transifex's lead, who created that
Trac test project ) to know a bit more about the options we have. The
Transifex FAQ is also quite informative [3], as is their (Trac!) wiki [4].
So let me start the discussion with the following few points.
Most large projects are delegating direct write permissions in the
repository to their translators; so far, no one has requested this for
Trac, but I can see how this could be a good idea, as this would
streamline the contribution process, and let translator have direct
control over the translations they contribute. This doesn't mean that
there couldn't be someone who takes care of the technical quality of the
contributions, checks that the correct tools are used, etc. In that
respect, Transifex used as a middle man would alleviate all the
administrative burden, as only one account would have to be created. The
technical details, whether we should get those contributions by e-mail
or use an intermediate dvcs repository are also open. Anyway, having an
official Trac mirror somewhere (be it a git or mercurial one, or both),
would be a nice thing in any case. Hosting our own mirror would also be
option, I imagine.
Transifex also has "Collections" of related projects (currently Django,
GNOME and LXDE). I can imagine a "Trac" collection in this picture, as a
way to collect all the translation projects for all the plugins, once
people realize they can already translate their plugins ;-)
Editing translations directly on Transifex's site is probably not an
option as of yet, due to the limitations of Lotte regarding the size of
the catalogs, but as I understand it, this is going to change.
While the ideal for getting high quality translations remain in my
opinion having people actually running Trac and testing their
translations to see how well they work "in context", having the
possibilities to get translations directly from a web interface doesn't
sound bad either.
As I was writing this mail, I got a reply from Dimitris, telling me he
handed down maintainership of the Trac project on transifex to me; Thanks!
I'll activate or not the submissions depending on the outcome of this
discussion.
-- Christian
[1] - http://www.transifex.net
[2] - http://www.transifex.net/projects/p/trac/
[3] - http://www.transifex.net/faq/
[4] - http://transifex.org/
Jeroen Ruigrok van der Werven
>As I was writing this mail, I got a reply from Dimitris, telling me he
>handed down maintainership of the Trac project on transifex to me; Thanks!
>I'll activate or not the submissions depending on the outcome of this
>discussion.
I'm not going to bother anymore when you are already leaning towards doing
that and just add me as an afterthought on cc: despite having been the
primary catalyst for it for about a year and a half now. And I know how
these "discussions" go, you will only push through what's in your head
anyway.
I'm done with it.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Alas! The world is full of enormous lights and mysteries, and man shuts
them from himself with one small hand!
Christian Boos
> The real question is if it would be a good idea to allow submissions
> from Transifex, what would be the pros and cons.
>
There has not been many replies to this mail, but offline, the answers
I've received from the other Trac developers were that it looks
promising and it would be worth a try, at least.
> Personally, I think this would be a good thing, and my immediate
> reaction was to wonder why the submissions were not yet activated... So
> I got in touch with Dimitris Glezos (Transifex's lead, who created that
> Trac test project ) to know a bit more about the options we have. The
> Transifex FAQ is also quite informative [3], as is their (Trac!) wiki [4]
>
A few questions for Dimitris first.
The Transifex FAQ says that when you get the .po file from Transifex,
you'll get the msgmerge'd version of it; that's good, as we don't want
to have to commit systematic mechanical updates to the various .po file
we have; doing it for the .pot file is already "noisy" enough; the
problem is that it doesn't appear to work: take for example
http://www.transifex.net/projects/p/trac/c/default/raw/trac/locale/ja_JP/LC_MESSAGES/messages.po
it's clearly not msgmerge'd. If you run msgfmt --statistics on it, you
get 843/18, not the 834/17/56 stats given by Transifex.
If I do a msgmerge by myself, I get 829/39/39, so quite different
numbers except for the total, which is indeed also 907. Using GNU
gettext-tools 0.17, if this is relevant.
So it looks like we have two issues: the stats are not reliable, and
most importantly, when you get the .po, even via Transifex, it's still
up to you to do the msgmerge... Not a big deal with clear instructions
given to the translators, but as it's different from what the FAQ says
(http://www.transifex.net/faq/#heading_toc_j_20), it's worth mentioning.
Second point, the fr_FR translation used to show up correctly on top at
about 100%, recently it dropped to 0%. Running msgfmt --statistics on
that messages.po file, I got:
fr.messages.po:3538: `msgid' and `msgstr' entries do not both begin with
'\n'
msgfmt: found 1 fatal error
907 translated messages.
This certainly explains the reason of the drop to 0%, but it would be
nice to have a way to see that error message from the Transifex
interface itself (if there's already a way, I didn't find it...).
-- Christian
Noah Kantrowitz
On Dec 20, 2009, at 10:26 AM, Christian Boos wrote:
> Christian Boos wrote:
>> The real question is if it would be a good idea to allow submissions
>> from Transifex, what would be the pros and cons.
>>
>
> There has not been many replies to this mail, but offline, the answers
> I've received from the other Trac developers were that it looks
> promising and it would be worth a try, at least.
There was, in fact, only one reply. A reply that anyone in their right
mind would say is unilaterally negative. To not address this would be
rather blatantly lying. But ya know, you could just do it anyway.,
--Noah
anatoly techtonik
>
> I was told that there were some concerns about this, and questions about
> the implications this will have for our translation process. So let's
> discuss this openly here. The statistics themselves are a non-issue, as
> this is merely informative and should have no consequences, other than
> perhaps motivating the translators to update their translations, of
> course ;-)
I hardly imagine what transifex is. Seems it support some translation
statistics. Good, but can you tell a bit more - what is the source
data by which statistics is built? What's wrong with translation
process now? And What are alternatives?
> The real question is if it would be a good idea to allow submissions
> from Transifex, what would be the pros and cons.
Do you mean write access to SVN or some licensing issues? If former
then that options do you have - limit SVN access only to translation
directory or to all repo? Will commits be done automatically meaning
some kind of bot imports them from outside? What is the risk of
getting some "bad language" as a consequence? Do they have "translate"
-> "reverse translate" -> "compare" process?
> Most large projects are delegating direct write permissions in the
> repository to their translators; so far, no one has requested this for
> Trac, but I can see how this could be a good idea, as this would
> streamline the contribution process, and let translator have direct
> control over the translations they contribute. This doesn't mean that
> there couldn't be someone who takes care of the technical quality of the
> contributions, checks that the correct tools are used, etc. In that
> respect, Transifex used as a middle man would alleviate all the
> administrative burden, as only one account would have to be created. The
> technical details, whether we should get those contributions by e-mail
> or use an intermediate dvcs repository are also open. Anyway, having an
> official Trac mirror somewhere (be it a git or mercurial one, or both),
> would be a nice thing in any case. Hosting our own mirror would also be
> option, I imagine.
http://mercurial.selenic.com/wiki/DeveloperRepos - very nice approach
to i18n and not only.
> Transifex also has "Collections" of related projects (currently Django,
> GNOME and LXDE). I can imagine a "Trac" collection in this picture, as a
> way to collect all the translation projects for all the plugins, once
> people realize they can already translate their plugins ;-)
What is this? Some kind of shared translation memory or just a bunch
of files in one named place?
> Editing translations directly on Transifex's site is probably not an
> option as of yet, due to the limitations of Lotte regarding the size of
> the catalogs, but as I understand it, this is going to change.
The best thing I've seen for editing translations is
http://translate.google.com/toolkit/
> While the ideal for getting high quality translations remain in my
> opinion having people actually running Trac and testing their
> translations to see how well they work "in context", having the
> possibilities to get translations directly from a web interface doesn't
> sound bad either.
I am not sure what does "get from we interface" mean. As for usability
and convenience to make a change - Trac installation can have link to
"report a better translation" or "suggest doc fix" with redirect to
Transifex, Google Translate or whatever.
--
anatoly t.
anatoly techtonik
toolbox for Trac. It is so easy - and you don't need to mess with .po,
.pot etc...
BTW, how Transifex differs from https://translations.launchpad.net/ ?
--
anatoly t.
> --
>
> You received this message because you are subscribed to the Google Groups "Trac Development" group.
> To post to this group, send email to trac...@googlegroups.com.
> To unsubscribe from this group, send email to trac-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
>
>
>
Christian Boos
On 12/20/2009 7:26 PM, Christian Boos wrote:
> A few questions for Dimitris first.
> The Transifex FAQ says that when you get the .po file from Transifex,
> you'll get the msgmerge'd version of it; that's good, as we don't want
> to have to commit systematic mechanical updates to the various .po file
> we have; doing it for the .pot file is already "noisy" enough; the
> problem is that it doesn't appear to work: take for example
> http://www.transifex.net/projects/p/trac/c/default/raw/trac/locale/ja_JP/LC_MESSAGES/messages.po
> it's clearly not msgmerge'd. If you run msgfmt --statistics on it, you
> get 843/18, not the 834/17/56 stats given by Transifex.
> If I do a msgmerge by myself, I get 829/39/39, so quite different
> numbers except for the total, which is indeed also 907. Using GNU
> gettext-tools 0.17, if this is relevant.
>
> So it looks like we have two issues: the stats are not reliable, and
> most importantly, when you get the .po, even via Transifex, it's still
> up to you to do the msgmerge... Not a big deal with clear instructions
> given to the translators, but as it's different from what the FAQ says
> (http://www.transifex.net/faq/#heading_toc_j_20), it's worth mentioning.
>
I repeated the experiment today, this time with submissions active, but
this made no differences.
I started with this in the repository (at r9027):
$ msgfmt --check --statistics trac/locale/cs_CZ/LC_MESSAGES/messages.po
688 translated messages, 2 fuzzy translations, 108 untranslated messages.
I then tried 3 methods of updating the catalog:
1) download from Transifex
wget
http://www.transifex.net/projects/p/trac/c/default/raw/trac/locale/cs_CZ/LC_MESSAGES/messages.po
-O tx.cz.messages.po
tx.cz.messages.po (106855 bytes)
$ msgfmt --check --statistics tx.cz.messages.po
688 translated messages, 2 fuzzy translations, 108 untranslated
messages.
$ diff tx.cz.messages.po trac/locale/cs_CZ/LC_MESSAGES/messages.po
(no output, it's the same file => there was no merge contrary to
what the FAQ says)
2) update using Babel
babel.cz.messages.po (131423 bytes)
$ msgfmt --check --statistics babel.cz.messages.po
601 translated messages, 100 fuzzy translations, 213 untranslated
messages.
3) update using msgmerge
msgmerge --update trac/locale/cs_CZ/LC_MESSAGES/messages.po
trac/locale/messages.pot
msgmerge.cz.messages.po (127763 bytes)
$ msgfmt --check --statistics msgmerge.cz.messages.po
601 translated messages, 113 fuzzy translations, 200 untranslated
messages.
Note that at the same time, Transifex shows 75% (688/2/224) for cs_CZ.
So ... either there's a bug or there's something I did wrong ;-)
The difference between babel.cz.messages.po and msgmerge.cz.messages.po
are mainly cosmetic ones (lines of different length, different fuzzy
guesses). But the tx.cz.messages.po is just the one you'd get from the repo.
Any hints appreciated!
-- Christian
Laurens Holst
Google’s web interface but that didn’t seem to work…)
Hey,
I haven’t used Transifex so I don’t know many details about that, but
Sunbird also has a web-tool that I do have some experience with. By
itself is convenient for casual changes, it provides a nice UI for
quickly being able to contribute a translation. Very low barrier of
entry, and perfect for quickly correcting that incorrect composition
that has been bothering you. The tool has several downsides as well though:
1. It doesn’t provide for a translation community and discussion of
translation-wide topics. There is no way to contact the other
translators. Individual strings can be discussed but I have the
impression that those comments are rarely read. For example, someone
recently changed about half of the strings to use the informal Dutch
form of you, and this change was not discussed nor applied consistently.
I am hesitant to change it back because I don’t want to start a
revert-war, and I would like future contributions to adhere to the same
form as well.
2. Nor is there a review process; any half-wit can change a translation
to be totally incorrect or inconsistent.
3. I personally prefer editing text-files by hand, a real text editor
gives you more flexibility wrt. searching. E.g. I do a lot of regex
searches to compare translations and make sure they’re consistent, and
that is not possible from a web UI, and neither is doing a global
search/replace and then comparing the differences with the current
strings before submitting it.
About actually running Trac, in my recent contributions to the Dutch
localisation I have not build and run Trac myself, however looking at
the source files and the running version of the old translation @
trac.edgewall.org was definitely a great help. You can’t translate
without context. I think it would be good if Transifex would provide
links to the English source files, dunno if it already does that.
As for write permissions to the repository, with the Firefox translation
one member of the Dutch localisation team is responsible for doing this.
The good part of a Dutch committer is that he can do some basic quality
control on what is committed, and of course understand peer review
discussions held in Dutch (which is more convenient than doing this in
English) and hold back on checking in patches until the discussion
finished. This person however does need to have a neutral attitude, that
is trying to achieve and follow consensus, so you can’t just pick anyone
for this job.
Wrt. DVCS, a Mercurial mirror repository would be nice. Managing
changes, especially if you have multiple sets of them that need to be in
separate patches, as is often the case with localisations as you want to
address parts that are still under discussion in separate patches, is
very bothersome without a DVCS.
~Laurens
On 4 dec 2009, 14:52, Christian Boos <cb...@neuf.fr> wrote:
> Hello,
>
> This morning I discovered that the Transifex hosting site [1] had
> integrated Trac as a test project [2]. As it stands, this mainly gives
> us an overview of the work in progress.
>
> I was told that there were some concerns about this, and questions about
> the implications this will have for our translation process. So let's
> discuss this openly here. The statistics themselves are a non-issue, as
> this is merely informative and should have no consequences, other than
> perhaps motivating the translators to update their translations, of
> course ;-)
>
> The real question is if it would be a good idea to allow submissions
> from Transifex, what would be the pros and cons.
>
> Personally, I think this would be a good thing, and my immediate
> reaction was to wonder why the submissions were not yet activated... So
> I got in touch with Dimitris Glezos (Transifex's lead, who created that
> Trac test project ) to know a bit more about the options we have. The
> Transifex FAQ is also quite informative [3], as is their (Trac!) wiki
[4].
>
> So let me start the discussion with the following few points.
>
> Most large projects are delegating direct write permissions in the
> repository to their translators; so far, no one has requested this for
> Trac, but I can see how this could be a good idea, as this would
> streamline the contribution process, and let translator have direct
> control over the translations they contribute. This doesn't mean that
> there couldn't be someone who takes care of the technical quality of the
> contributions, checks that the correct tools are used, etc. In that
> respect, Transifex used as a middle man would alleviate all the
> administrative burden, as only one account would have to be created. The
> technical details, whether we should get those contributions by e-mail
> or use an intermediate dvcs repository are also open. Anyway, having an
> official Trac mirror somewhere (be it a git or mercurial one, or both),
> would be a nice thing in any case. Hosting our own mirror would also be
> option, I imagine.
>
> Transifex also has "Collections" of related projects (currently Django,
> GNOME and LXDE). I can imagine a "Trac" collection in this picture, as a
> way to collect all the translation projects for all the plugins, once
> people realize they can already translate their plugins ;-)
>
> Editing translations directly on Transifex's site is probably not an
> option as of yet, due to the limitations of Lotte regarding the size of
> the catalogs, but as I understand it, this is going to change.
>
> While the ideal for getting high quality translations remain in my
> opinion having people actually running Trac and testing their
> translations to see how well they work "in context", having the
> possibilities to get translations directly from a web interface doesn't
> sound bad either.
>
> As I was writing this mail, I got a reply from Dimitris, telling me he
> handed down maintainership of the Trac project on transifex to me;
Thanks!
> I'll activate or not the submissions depending on the outcome of this
> discussion.
>
> -- Christian
>
> [1] -http://www.transifex.net
> [2] -http://www.transifex.net/projects/p/trac/
> [3] -http://www.transifex.net/faq/
> [4] -http://transifex.org/
--
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com