[Debian-l10n-devel] Thoughts about DDTP (Was: Number of requests for DDTP)

Martijn van O kleptog at gmail.com
Sun Jul 31 11:44:53 UTC 2011


Thanks for your thoughts, response inline.

On 31 July 2011 09:57, Aron Xu <aron at debian.org> wrote:
> Definitely I don't know the web interface can produce PO files, or I
> won't convert it by myself.

Ok, here's some things that might be useful to you:

All untranslated packages:
http://ddtp.debian.net/ddt.cgi?alluntranslatedpackages=zh_CN

Once you have the desc_id, you have:
http://ddtp.debian.net/ddt.cgi?desc_id=80182&getpountrans=zh_CN
To get a PO file. Use "getuntrans" if you just want the normal format.

> It's being converted to PO format, upload to Pootle, translators do the
> work, convert back and send to the email interface, that's all.

Aha, right. Note, the email interface isn't bad if you're actually
translating all those descriptions. But if it's just for information
retrieval and getting translations, pulling from the web interface is
better.

> Honestly, our translators (zh_CN) said they don't like DDTSS's interface
> and it's complex work flow (i.e, need three people to work on one
> translation to let it in, by default settings of DDTSS, you already know
> the manpower is always very limited). In other translation projects
> which work on software interface, they usually have a translator <->
> reviewer interaction, that is anyone can submit a translation, and
> someone who is given the privilege can review it and decide.

Ok. I find it odd that when I asked years ago about what work flow
people wanted, zero people responded. If the default settings were
bad, they could be changed. But recently I've heard of other groups
that would like the "trusted reviewer model" and so I'm working to
make this easier (it's of course possible in the current system, but
it's not forced).

> That's why we try the Pootle approach because translators are at least
> more familiar with the interface, though it's obviously not an ideal
> solution. It has its shortages:
>  1. Need a lot of work to be done to integrate it with current DDTP
>  backend.

I must admit I understand very little about Pootle. Although I've just
noticed it is Python+Django, just like the new DDTSS, so perhaps it
wouldn't be that hard.

>  2. It's not seriously translator/reviewer model. Though we can let
>  translators only "suggest" and reviewers decide, translators cannot
>  feel they are a part of the team, they get the feeling that they are
>  not that welcomed and the project is only the toy of several people who
>  do the reviews. In a word, it discourages collaboration.

Which is why I don't like separating people into groups
translator/reviewer. But people apparently want that...

> Translators don't like to work on a project with no statistics,
> especially when the project does not tell them about the percentage of
> progress. This is why all major open source translation collaboration
> platform generates graphic statistics for translators (Transifex,
> Pootle, Launchpad, etc). I know there *are* statistics published for
> overall progress and popcon top 500, etc. But the fact is translators
> cannot find them easily. It's not a matter of whether we have
> documented it, it's a matter of user interface design.

If there are statistics that would help, suggest them. The DDTP has
always been hampered by lack of manpower and that translators don't
communicate what they actually want. The data is in a database and we
can produce any statistics you want, I just have no idea which
statistics would be interesting.

You're right it's about user interface design. This is one of the
reasons I'm using Django to separate the user-interface from the code
so non-programmers can contribute in the user-interface. So far it
hasn't helped, but I'm hopeful.

> DDTP is a huge project, and people get discouraged when they worked for
> some while and the progress hasn't been pushed forward 1%. Debian has
> thousands of packages, and even more descriptions await for translating.
> Why not we set several milestones, select some packages for different
> milestones. The selection could be classified to different target
> audience, for example, "Desktop", "Programming", "Server" or by whatever

This sounds like a good idea though. We don't currently have all the
information needed to achieve that, but I think it's nice. It also
gives me idea on how to choose which packages are next. My first idea
is to base milestones on Debtags, and you can then show progress per
tag.

But, there's limited manpower of course (the eternal problem) :).

> As for the collaboration model, I think what I've written before in this
> mail is better, at least it has been tested overtime by many projects.
> "Submitting" translations to someone who is skilled is accepted by most
> people, so they don't need to be shy and worrying about "what if my
> translations are bad?" They can communicate with a specific person (not
> letting them write to a mailing list, with fears of being teased because
> of his ignorance).

I think you mean the "anyone submit, trusted reviewer" model? I
would've thought the pseudonymity would make it easier for people.

> Then we come to the topic about some detailed designs, and why Pootle
> discourages people. Translators can be roughly divided into two
> categories: long-term contributors and random ones. They both need to
> have the ability to "submit" translations to who can review their
> translations, not just "suggest". Suggesting translations on a
> translation platform is always about to be ignored by others, and
> this is why Pootle does not work well. What they need is to "submit",

Indeed, I've always wondered about the difference between "submitting"
and "suggesting". It seems the same to me. That's why I always
preferred the model: anyone can submit, anyone can review and make
improvements, you just need to provide good controls on what is
accepted. AFAICT what people suggest are really just more restricted
versions of this.

Have a nice day,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/



More information about the Debian-l10n-devel mailing list