Rosetta-Feedback - UDS Prague

[Danilo Šegan]

Hi Kenneth,

On Saturday at 15:47, Kenneth Nielsen wrote:

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

You make it sound like it's a few minutes of work, when it's anything
but. :)

The only capability we lack at the moment is making comments for
rejected/modified suggestions.  All the other steps are possible, and
actually easier with Launchpad.

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

I agree 10-strings-per-page is too low for serious review work.
However, knowing that you are not a newbie, I'd be surprised if you
haven't found a way to enlarge that number :)

However, I find that one click is hardly a limitation.

(Btw, I'd leave the decision to usability guys)

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

Thanks for taking the time to describe this here.

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

That's what you do by approving a suggestion.

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

So, you want to have several people 'signing off' on a suggestion?
What I wonder is will that be used at all, and if it will, will it be
used on more than 1% of strings.  My suspicion is that no, it will not
be used on more than 1% of strings, meaning that 99% of messages will
have UI more cluttered (our UI is already too complex imho).

This is basically 'voting' per message, and I think that's simply too
much.

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

This sounds like a cool idea, but also sounds pretty hard with our
current DB model (i.e. this is a big architectural change, basically,
svn vs. cvs style: in SVN one revision holds all changes from a single
commit, in CVS each file has their own revision numbers and it's hard
to find what was committed together).

As far as 'old style' diffs are concerned, I'd mark that off as
'impossible' right away.  Regular diffs of PO files are useful only
for looking at, and not for much else.

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

A lot of 'light requests' are not so light when you are working with
tables with millions of rows.

Anyway, I agree this would be a nice feature, but I'll also be
honest: something like this is not going to happen in the near future.

Big reason for that is: people have not even used our existing review
features to an extent that would make us believe that even this simple
system is really desired.  I understand that lack of commenting is
seriously hurting, but that is a much lighter change and can solve
most of the problems this feature solves as well.

> 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

I love the idea that you are proposing how the translator who gave
original suggestions should fix them before they are approved.

However, I'd remove the entire complexity of your 'point-diff'
approach, and instead just show a page with all unapproved suggestions
by a certain translator for a single PO file (we already have
something very similar, but it includes approved and obsolete
translations as well, though highlighted with different text colours),
have a reviewer comment on that, and send that to a reviewer.

And I believe you can mostly carry on this work-flow in existing LP,
with the difference that you have to do the communication outside LP.

I.e. take a look at

  https://translations.launchpad.net/ubuntu/gutsy/+source/debian-installer/+pots/debian-installer/da/+filter?person=astalyberth

There you'd see all the suggestions a guy has made, and you can
consider all regular-text suggestions as 'point-diff' (bold ones are
approved, gray rejected: none on this specific page, but on other
ones).  You can copy and paste this page into email, add some
comments, and similar.

It won't be hard for us to provide an 'only new suggestions' filter
for this page, and it'll be simple to provide an 'Approve all' button
to reviewers.

Cheers,
Danilo