Rosetta-Feedback - UDS Prague

[Kenneth Nielsen]

2008/6/18 Danilo Šegan <danilo at canonical.com>:

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


Yeah I know :) But that is also the reason why it is important a) to make
sure that the workprocess is stripped of anything that will make in in
effective and b) that it is possible for you to make as sure as you can that
your work will not go to waste. I'll return to this, becasue that is
actually one of my points


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


Ahh well, I guess that depends of what tools people prefer. If it will
require me to mouse-click the "return with comment" button in order to have
the text field appear where I can write the comment I still _prefer_ the old
way. BUT that is purely a matter of me being old :) and I could defenitily
get used to working with a multiple mouse-clicky web-interface once we get
these few more features in ;)


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


Yes I have. But surely you agree that I shouldn't have to do it like that. I
believe an LP a settings page, where I can choose to always have 50 strings
shown at a time when I'm doing reviewing or even translating, somewhere on
my personal LP page would be in order. You (or the usability guys) can bury
these options as deep in the GUI as you want to not mess with the
simplicity, as long as it is there to find if you know where to look


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


Ahh well. One click and 5-10 seconds of waiting for the page to load for
every 10 strings for review, GNOME e.g. has ~35000-40000 strings and ~10-15%
replacement or addition every 6 months, I'm sure you can do the math. (I
know that it would also take time to load a big page, but that will be 1
much bigger chunk of time in stead of many small. The bigger wait I can use
for something else, I can't do that with the many small)


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


Ahh I guess I didn't explain it correctly. I didn't mean to make it a voting
but simply make it possible for 1 person to have his name on all the
suggestions for one translation, either a the "suggester" or, if an adequate
suggestion have allready been made, as the "co-suggester/signer"


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


Ok. But maybe it isn't necessary. I think some of the stuff you write about
further down will make us come along way.

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.


I didn't mean that they should be implementable in a diff/patch kind of way.
But purely for review (reading and commenting). We do all our GNOME review
work with ordinary text diff's created by a script, which ensures that you
always have a the entire chunk of text pertaining to a string as context, in
stead of a fixed number of lines the way the normal diff command does.


> > 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'm not sure that is a fair argument. Speaking of course only for myself, I
have not the using review system in LP because I, up untill very recent,
didn't consider there to be a review system I could use, that wouldn't
seriously waste my time. So no, also based on some of the discussion on the
GNOME channels about the this, I think there is a need for such a system, I
just needed to mature a little.

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.


Agreed this should have i high priority, implementing that would, in my head
at least, make LP-translations cross the line to where it is something I
could imagine using on a big scale.


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


Oh yes, add a sorting mechanism to that page (and perhaps have your design
team take a look at the layout, i.e. have them put the date in a column on
its own, so the original string and the translated one is right below each
other, makes for easier reading) and that would provide a very nice solution
for us.


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


Oh yes and off course adding the commeting feature on the same page would
make it almost perfect.


> 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


actually female ;) but that it besides the point


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


Nice nice nice. For a very large part of the work this is a very good
solution.

There is only one remaining concern, which is the one that I noted earlier
in the mail. You see the point of my original suggestions was not only to
make it easy to review, but also to have a person committed to the process,
to make sure that my reviewing work does not go to waste. I will illustrate
with an example, assuming that the solution you suggest above has been
implemented.


===
Module "ex" has 400 strings that needs to be either translated or updated.
Three persons have been working on it over the time, but it was only
recently that person A made the big push and added suggestions to all the
strings didn't have suggestions already. So now that status is such that A
has made 80% of the suggestions and B and C each 10%. Person A followed the
(imaginary) instructions on the Danish teams main page and contacted me and
asked me to review her work. I used the reviewing mechanism you described
above, a page per person per translation, added comments, she made
correction and I approved them. The questions is now what. There is still 80
strings left in the translation and A is asking me what to do about it.

You see, the reason for me to suggest "signing of" on suggestions was partly
to be able to fix this. I don't want to make comments on B and C's strings
because I have no guaranty that they will bother fixing it or even that they
will ever get to read the comments. There is nothing A can do to "adopt" the
strings and there is nothing I can do to review them to let her work with
the comments. Letting her sign of on the strings would allow them to appear
on her page of suggestions, and hence I can review them and she can work
with the comments. I agree that if this is the only remaining concern, my
"sign of" suggestion is probably to heavy, do you have an idea of how to
work around it. I can think of a few myself.
One would be to make the comments public(I don't what the plan is now), so
that after A has agreed to, she could easily read the comments I made for B
and C and finish the remaining strings (once some time has passed, so that
we are sure that they are not coming back to do it them selves). The only
concern with this solution is if B or C would feel unhappy having their
typos and grammar mistakes displayed publicly. I don't that is to much of a
concern though.
Another suggestions would be to make it possible for A to volunteer herself
as being responsible for the translation of module ex. Then make it so that
the responsible person can always see all the comments and fix the strings.
This involves some more work and would essentially only be required to get
rid of the privacy issue mentioned above, though I could possibly be used
for other stuff as well.
===

All in all I think that what you are suggesting above would make for a very
elegant solutions to the problem. I can think of some ways to add small
pieces of niceness to it, like adding the possibility to do the
communication inside LP, but that is all details we can work on later.

Reagards Kenneth Nielsen

BTW: Do you have a comment on my comment (starting to confuse myself here)
about module groups

> Indeed. Regarding making e.g. ubuntu-desktop groupings, from my point of
> view, as a person the worries about Ubuntu-upstream contribution conflicts,
> it would be much more useful to have groupings based on the upstream
> locations of the package, say make a GNOME-group, KDE-group, XFCE-group,
> TP-group, LP-group and "Scattered upstream"-group. That would make it very
> much easier to explain to a newcomer what he should do to contribute to a
> speceific package depending on which group it is in.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-translators/attachments/20080618/c35769b8/attachment.html>