Rosetta-Feedback - UDS Prague

[Kenneth Nielsen]

Hallo Sebastian

It sounds like you guys had a very good discussion and I can whole-heartedly
sign off on all of your points. Especially I think that you with 1, 2 and 3
have essentially captured the essence of my last nerveous breakdown ;)

There is one point that I would like to elaborate on and that has to do with
reviewing and QA. I think that right now there are a lot of suggestions for
how to improve the LP UI to make this better and easier and that's fine, but
I think you have to consider making a policy change considering LP that
allows people to take part of this job outside of LP as an option. The
problem is that the people that currently work as admins and reviewers are
"old" guys who has previously worked with upstream projects, and for them/us
the LP way looks like a lot of unnecessary mouse clicks and wasted time.
Upstream, say in GNOME, you might have a process like this:
* A translator sends a diff-file that represents his latest translations
contributions to a list for review
* The reviewer opens the diff in his favorite text editor, say emacs,
comment on the strings that need commenting and delete the rest, send that
back to the transator
* If the translator agress with the comments he makes the changes and sends
the finished file for integration ---
* which is accomplished by a couple of svn commands by the admin

So all in all, a couple of emails and some pure text editing and it's done.

Considering this, any review process that require one mouse click per
string, and possible waiting for a page to load for every 10 strings you
want to review and has no "built-in"/easy posibility for feedback, is just
to much trouble .

Therefore I think it would be very nice to have a process in LP that mimics
parts of this process simply because it is so easy, and I do have en idea on
how to accomplish this. I involves two different expansions/modifications to
LP and therefore do include some work on the part of the developers, but I
think it would be worth it. I have written the idea out below, I was
planning to put these in development specifications but I have been crazy
busy the last 10 months with my masters thesis work (and will be so for the
next few months also). Suggestion 1 is only a tool needed for suggestions 2.


1) Making it possible to "sign of" on a translation suggestion
Description: This would be an option to say that you think that an already
existing suggestion is good, and that you would have made the same
suggestion if it wasn't already there.

Implementation considerations: UI-wise this would require a little button
next to the suggestions and a link in the string that contains the source of
the suggestions, where you could see the people that have signed of on the
suggestion. I think this represents very little of "UI-cluttering" that
Danilo mentions that he would like to avoid.

2) Making it possible to store a set of suggestions and approve/implement
such a list with one action
Description: After going through a translations and making as many
suggestions or signing of on others ^^ it should be possible to save a list
of all the suggestions _you_ made or signed off on as some sort of an object
(lets call it a point-diff) and give it a name. It should then be possible
to see a list of such point-diffs, to export them as a old style diff and to
approve/(implement the changes the describe) them with just one action as an
admin and possible to proofread them and provide text feedback on a
point-diff basis directly in LP.

Implementation considerations: All of the functions to save such and object,
export them, see a list of them and approve them, could be put in a menu
somewhere and hence shouldn't introduce any "UI-cluttering". The other thing
to consider is strain on the databases and servers. I imagine that
suggestions are already stored os some sort of an object so such point-diff
could consist simply of a list of objects which db-wise should be relatively
light. Making the real text diffs for the export can be calculated
relatively lightly on request and therefore does not have to be saved.


With the two suggestions above it would be possible to implement several
different work flows, depending on how much of the work you want to do
directly in LP, and do it in a way that would be both simple for newcomers
and be light in administrative duties. I have scetched two different work
flows below, one which is very close to an upstream mail-list-proofread/SVN
method and one which is purely LP.

1)
* When a translator wants to update a translation you advise him to look at
all the strings that need attention and either make suggesions in his own or
sign of on other peoples
* After this he saves all this work as a point-diff, exports it and sends it
to a mail-list for review
* He gets feedback and corrects the strings that needs corrections and make
a new point-diff and sends the name of the new point-diff to the mail-list
* The admin finds this latest point-diff and approves it in one stroke

2)
* When a translator wants to update a translation you advise him to look at
all the strings that need attention and either make suggesions in his own or
sign of on other peoples
* After this he saves all this work as a point-diff
* The reviewer who is notifed of this latest point-diff, either by some sort
of subscription in LP or directly by mail from the translator, finds it,
reviews it in LP and sends point-diff specific feedback to the translator,
could be via LP
* The translator is made aware of the feedback to the point diff, implements
the corrections and saves a new point-diff,
* The admin, who is notifed of this latest point-diff, either by some sort
of subscription in LP or directly by mail from the translator, finds this
latest point-diff and approves it in one stroke

(Note that in the implemetations above it is not becessary with a permission
handling that is any more sofisticated than it is now, and that the admins
and reviewers I mentions could be the same)

Let me know what you think about this idea.
Regards Kenneth Nielsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-translators/attachments/20080614/46846207/attachment.html>