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

[Aron Xu]

On Sun, Jul 31, 2011 at 01:44:53PM +0200, Martijn van O wrote:
> 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.

The first link only shows about "active" ones, where are others?

> 
> > 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.
> 

Yes.

> > [...]
> 
> 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).
> 

At that time I hadn't jumped into DDTP, ;-) So this time is a chance
to discuss.

> [...]
> >  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...
> 

Well, I suggest to look at the GNOME approach, damned-lies. It is
translator/reviewer model, but because all information will be sent to a
mailing list, we are able to establish a sense of teamwork. Of course
it's not only because the platform itself, all team's coordinator must
work hard at the starting period of the team to establish such kind of
sense.

> > 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.
> 

Simply add a progress bar is sufficient for most people. Graphics with
texts is much better than only texts, :)

> > 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) :).
> 

The company behind linuxdeepin.com is planning to investigate some
manpower to help the translation tools of DDTP later this year. I will talk
with them discussing about our current situation.

> > 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.
> 

Yes, "anyone submit, trusted reviewer", and of course the submitter can
choose whether to register an account. If he registers, everyone in the
team will be able to know him (if we can send mail notifications about
submissions and reviews), this is very helpful for keeping long-term
contributors and build the sense of a team. 

> > 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.
> 

As I am also a translator of some other projects, I can think of some 
differences between "submitting" and "suggesting":
 1. Suggestions tend to be ignored by reviewers or other people.
 2. Suggestions won't cause any change on the collaboration platform,
 which means it won't change the overall progress, neither let others
 know someone has worked hard on the items - yes, we can mark the
 strings are "suggestions available", but we'd look at 1 again.
 3. Suggestions are just "suggestions", so translators don't need to
 care about quality, "they are just suggestions, give those other guys
 a chance to improve it."  And this is why we have "1".
 4. Suggesting means there is a core team, we can only "suggest" to
 them, but we are not the team. This results in that the contributor
 can't feel she's part of the team.

On the contrary, "submitting" means: 
 1. Submissions will be reviewed one by one, though there might be a long
 waiting time (the reviewers might be busy), but the translator is sure
 that there will be someone to do it eventually. 
 2. Submissions is always be considered as a more formal way of
 contributing. The collaboration platform will instantly change the status
 of that item to something like "Pending review" or "Translated". This
 means the submitter is actually "translating", not just "suggesting". 
 3. Having a sense of real "translating", not the dispensable
 "suggesting", people will have a sense of responsibility. This will let
 them more concentrate on the quality. And of course, if they wait for a
 reviewer for too long, they are very probably to ask "is there anyone
 who can review my translations?"
 4. Although the translations have to be reviewed by some specific other
 people, they get the sense of a team member. The difference between
 reviewers and translators is just they have different role with
 different work in a team. Communications could start when translators
 have questions, or a reviewer thinks something is correct but there are
 cons.


-- 
Regards,
Aron Xu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-l10n-devel/attachments/20110731/f4efb7db/attachment.pgp>