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

[Alexey Balmashnov <a.balmashnov@xxxxxxxxx>]

On Thu, Aug 20, 2009 at 5:45 PM, Karl Fogel<karl.fogel@xxxxxxxxxxxxx> wrote:
> With the 3.0 release coming up soon, we're beginning the 4.0 planning
> process.  To help with prioritization, we'd like to know your top 3
> wishes for Launchpad 4.0.  Please follow up in this thread, and...
>
>  *** *** ***
>  Don't change your response based on other responses in this thread.
>  *** *** ***
>

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?

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.

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.

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.

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.


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.

Thanks for reading through.

Cheers,
  Alexey