Re: [Launchpad-users] Your top three wishes for Launchpad? (4.0 planning)

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Hi Alexey,

Thanks a lot for your input.  A few comments inline.

У пон, 24. 08 2009. у 19:47 +0200, Alexey Balmashnov пише:

> Somewhere in the thread it was pointed out, that translators do not
> wish anything. May be because for a while already work on improvement
> of translation tools and processes was sort of low priority?

No, I believe it to be because it was from a different kind of
translator: the one working on an upstream project hosting their
translations in Launchpad. Where you are talking about translating
Ubuntu which has a whole lot more complications. ;)

Also, there are not many translators on this list.  We have recently
done a separate survey for translators (actually, David Planella has),
and we'll be using that as input as well.  And I am pretty sure I've
seen some of your items there as well :)

> So, here we go, on the translations front... I would love if there
> were tools available to structure the translators work.
> 
> 1. Some sort of locking strings/permissions mechanism
> 
> There is no automation of the translation propagation to upstream.
> Want to cooperate with upstream? Get your hands dirty and do it by
> hand. But... There is no indication or whatsoever that strings to be
> translated are actually different from upstream, or not at all used in
> upstream. If one translates something, he has no clue whether this
> string might be already translated elsewhere/upstream, which surely
> leads to a  duplication of work, difficulties in merging translations
> with or from upstream, which finally results in tensions between
> translators working on Ubuntu and upstream. One of the possibilities
> here might be in clear indication, that strings are unique to Ubuntu
> and ability to focus translation work around them, for example, via
> locking strings that for sure are coming from active upstream projects
> like GNOME.

This is related to how Ubuntu packages provide their translations to
Launchpad.  Note that this is a problem only for new English messages:
any changes in translations already show up appropriately marked.

But all the problems you see can be avoided in a few different ways
(like, doing continuous imports of upstream translations and enabling
message sharing between upstream projects and Ubuntu should solve the
duplication of work and any difficulties in merging translations
around).

> Another possible use of lock mechanism.
> 
> It might be also employed in the translation process, when
> reviews are being performed, e.g. upon finishing translation and
> review string gets frozen without ability of most translator team
> members to change it directly, but only make suggestions. It might be
> based on translator quality/experience ranking based on voting system
> or somehow else.

Note that this is entirely different from the above problem (the mere
fact that you call both features "locking" doesn't make it the same
thing ;), so it counts as another wish :P

> 2. Categories (tags?) to structure translatable entities
> 
> It is difficult to focus translators work on particular distribution
> or part of distribution. Currently, all translatable packages are in
> one huge non-categorized list. If translators team or part of the team
> wants to focus work on the particular flavor, extra
> organizational/administration is necessary. Yep, there are some highly
> weighted items on top of the list, like installers, documentation etc,
> but even this part of the list is messy. Clear categorization of the
> translatable packages/items by
> - flavor: ubuntu, kubuntu, ...
> - availability: e.g. installed by default vs additionally available
> applications in repositories + indication of applications popularity
> - activeness of upstream
> etc. May greatly improve translation process and quality of the
> distribution translation delivered to the end-user, which means better
> user experience.

That's probably coming soon: we are going to model it after the
packagesets implementation in Launchpad/Ubuntu.

> 3. Preview of translated documentation
> 
> Translation process for documentation based on Rosetta
> does not take into account, that translations normally should be
> reviewed as a whole. When a number of people are translating
> particular document paragraph by paragraph, you may see this directly
> in final translated document, when you read it as a whole. Number of
> issues here. Once one is busy with chunk by chunk translation, the
> style considerations for a totality of your work are the last ones you
> think of. An even if one wants to check and proof-read final version
> of document, he/she should dig into so many technical things (bzr,
> xml, xsl, figures etc) to get the overall view on the translated
> document with a hand-driven process like: download document from
> Rosetta - generate xml/html representation of the document - read.
> Further on, upon proof-reading, all changes should be made directly in
> the Rosetta with repetition of the download, merge, generate
> proof-reading cycle.

Yeah, this would be great: native support for XML documentation in
Launchpad.  The problem might be a plethora of different documentation
formats around, but supporting one or two well should be good enough for
start.


> NN. Small bonus... [Colored] Diff-s.
>
> Suggestions and variants of translation are nice, but they
> pretty much loose their value, when someone can not recognize in a
> blink of an eye the difference between translation variants. Area of
> improvement.

Yeah, that'd be nice, but that would be your fifth wish ;)

Cheers,
Danilo