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

[Michael Bramer]

On 07/31/2011 09:57 AM, Aron Xu wrote:
> On Sat, Jul 30, 2011 at 02:05:34PM +0200, Martijn van O wrote:
>> On 29 July 2011 11:22, Nicolas François
>> <nicolas.francois at centraliens.net>  wrote:
>>> We need to understand more about your use case.
>>> What are you doing with the files received from DDTP?
>>>
>>> Do you need all the descriptions?
>>> How often do you need to update the descriptions?
>>> How often do you need to receive translations contributed directly on
>>> DDTP?
>>> How often will you re-inject translations into DDTP?
>>>
>>> If you are creating a PO file (or multiple PO files), could we generate
>>> this on the server and make it available to you and others?
>>
>> This brings up a point, there are a number of functions in the web
>> interface that are not well documented. For example, the web interface
>> can produce PO files directly, for example.
>
> Definitely I don't know the web interface can produce PO files, or I
> won't convert it by myself.

Also the mail interface can/should import/export po files...
(I should check this)

>> So, I'd also be interested in what all these emails are used for
>> (especially given the side-effects).
>
> 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.
>
> 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.

We can change the number of reviewer per language...

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

ok

> I might need to explain more about why our translators don't like the
> current DDTSS, and why Pootle discourages collaboration in this scope.
>
> 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.

ok, I understand.

We have all the data in the Database and we can make a more nice
statistic page (per language).

> 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
> way that we can have further discussions. More over, we can have several
> milestones for every set of packages, sorted by popcon score.
> Translators and their teams can choose the sets and milestones they
> would like to work on first, and what later. This can even form a more
> efficient competition between teams, languages.

ok, nice

maybe this milestones:
  - priorities (required, important, standard, optional, extra)
  - sections (games, ...)
  - tasks from the packages-files
  - a custom package selection per language (defined from the lang 
coordinator)
  - maybe a custom package selection per user, defined from himself

If the user fetch a new description, he get one from his selected
milestone.

(we had something like this in the past in the old mail interface...
yes the good old times :-) )

Comments?

Gruss
Grisu