Re: Next steps improving Rosetta

[danilo@xxxxxxxxxxxxx (Danilo Šegan)]

Hi Timo,

On Tuesday at 13:48, Timo Jyrinki wrote:

> Thanks for the feature that we can now finally fix the possible damages
> done in Rosetta by selecting the "Packaged" translation, and keep the
> improvements so that we can at least manually send them upstream.

You are welcome: there are more improvements coming for Translations :)

You may be surprised at how much our ideas match.  And entire team is
now in the sprint, and we are discussing further improvements, and
when can we get to what.

> I hope all the best to those languages that took everyone willing to
> their teams and had more havoc than our language (Finnish). We had some
> damages, but nothing that we now cannot repair. And if some language
> team still hasn't established any clear requirements for the members, I
> recommend having such. QA is still too hard to do in Launchpad to accept
> any willing people to the translation teams.
>
> I'd hope to see the following improvements in Rosetta in the future:
>
> 1. "mass revert", meaning an upload PO file option where one can select
> "treat this as upstream and overwrite any Rosetta changes". I've
> currently clicked through eg. one package's 400 changed in Rosetta
> strings, in both gutsy and feisty, that were caused by an earlier manual
> upload of upstream translation that is now outdated but marked as having
> been done in Rosetta. mass revert would be very welcome if we had more
> packages like this

Already planned, but as a manual step per PO file:

  https://blueprints.launchpad.net/rosetta/+spec/revert-translation-to-packaged

> 2. This one would be _really_ welcome: A new column, maybe optional, to
> the translations list called "Changed in Rosetta", that has the number
> of changed strings in Rosetta per package. This would allow us to sort
> by the most changed packages and examine those in more detail, possibly
> reverting to upstream or taking the improvements to upstream.

Discussed during the sprint:

  https://blueprints.launchpad.net/rosetta/+spec/translation-status-for-reviewer

> 3. Download option "download only changed". This would allow for a
> neater way of having the improvements to be sent to upstream. Currently
> I've left the improvements I approve in Rosetta, and sent an URL to the
> changed strings in a package to the GNOME upstream language team leader,
> who is luckily in our translation team too and willing to copy-paste a
> few tens of strings from the web pages to the SVN translation files.

Also discussed during the sprint:

  https://blueprints.launchpad.net/rosetta/+spec/export-changed-in-launchpad
  https://blueprints.launchpad.net/rosetta/+spec/export-new-translations
  https://blueprints.launchpad.net/rosetta/+spec/export-incremental-translation-tarball

(the last one would include all the changed or new translations in LP
compared to packaged; reasoning for having 3 at the moment is on the
respective pages)

> Could you consider these in your future plans, if they're not there yet?
> In a short term, the 2nd improvement would be the most welcome, since it
> enables teams to check for possible bigger damages more easily. Of
> course, if big damages are found, 1st improvement could be very handy.

Today is our last day of the 'sprint' (a get-together where we discuss
our future plans, and make a concrete plan for the next 2-3 months).
We'll consider your input when setting priorities for the blueprints,
and set "milestones" for the future:

  https://launchpad.net/rosetta/+milestone/1.1.8 (late August)
  https://launchpad.net/rosetta/+milestone/1.1.9 (late September)

Note that it commonly happens that some items move from one cycle to
the next, since it's hard to predict design/programming/testing effort
needed.  So, the above links don't show exactly what will happen when,
but should be a good approximation once we fill them up.

> Btw, I tried to use Firefox extension to automatically select "Packaged"
> form items on a page, but unfortunately the names of the items are IMO
> unidentifiable from others.

If we don't come to implementing per-po file reversion in the short
term,  I'd suggest you make a blueprint describing what feature do you
want or need (none of us is familiar with Firefox extension you might
be using or trying to write).

Cheers,
Danilo