Add the ability to lock translations managed by upstream teams

At the moment, we don't want to allow locking of translations (until we spend more time figuring out the right privilege model for doing translations).

For instance, that metacity template you linked to might actually have modifications specific to Ubuntu: if we allow locking it, some teams might decide to do it without understanding the consequences and it would result in incomplete translations. Thus, we can't properly introduce locking without first figuring out which bits are Ubuntu specific and which are not.

Work-around for the problem you are currently facing is to limit access to ubuntu-l10n-fr team to only established reviewers, and to make sure that communication happens between team members (so they understand what they can or cannot do).

I guess that 95% of Ubuntu packages doesn't have Ubuntu specific strings. What is on Launchpad translations is mostly a fork pf upstream translations.

The feature that Severin request is the ability for local translation team administrators to lock some templates for everybody. This will prevent users (non members) do to useless suggestions in those translation templates. This will also avoid to see dozens of Launchpad contributors names in translators credits.
Like many other teams we already have a good list of Ubuntu specific apps and docs, and our team members usually know what they can do or not. The problem is that everybody can make suggestions everywhere...

There's also a potential issue with the Cannonical copyright at the bottom of Launcpad translations pages, but it's another problem..

У нед, 30. 08 2009. у 21:23 +0000, Bruno Patri пише:
> I guess that 95% of Ubuntu packages doesn't have Ubuntu specific
> strings.

And that's exactly the problem: you have to *guess* which packages do
and which don't have Ubuntu specific translations. There's no point
trying to fix this problem before we fix that first.

To prove a case in point: metacity, which is brought up as an example,
has the following patch in Ubuntu package:

- workspace_names[i] = g_strdup_printf (_("Workspace %d"), i + 1);
+ workspace_names[i] = g_strdup_printf (_("Desk %d"), i + 1);

(and a bunch of other string changes doing s/workspace/desk/)

Practically, anyone's guess is useless until we come up with a mechanism
to figure these out automatically.

> What is on Launchpad translations is mostly a fork pf upstream
> translations.

Let's get some facts straight first: Ubuntu includes *forks* of upstream
packages (like all distributions do). Launchpad enables translation of
such forks and uses the upstream translation as the base. If you
dislike how Ubuntu ships forks of upstream packages, you should bring
that up elsewhere.

We *are* interested in figuring out more details about Ubuntu packages
and how they are modified from their upstream sources, but it's simply
the data packages are not providing *yet* to Launchpad.

> Like many other teams we already have a good list of Ubuntu specific
> apps and docs, and our team members usually know what they can do or
> not.

Apparently, everyone can miss a few. Was metacity with its changes on
your list?

> The problem is that everybody can make suggestions everywhere...

Why is that a problem? Do you repeatedly see people making new
suggestions on already translated messages? Or did you see that in the
past?

Also, note that Ubuntu rolls out language pack updates even long time
after upstream has continued supporting a certain version (i.e. we might
get a hardy language pack update, even if GNOME 2.22 is not getting any
translation updates anymore). Locking translations would be counter
productive in that case as well, especially since we are going to enable
translations sharing between all active Ubuntu releases.

> There's also a potential issue with the Cannonical copyright at the
> bottom of Launcpad translations pages, but it's another problem..

I am not sure what do you mean by this? The only mention of (c)Canonical
I see there is for the web page, and I can't see how's that a problem.

Danilo, we are trying to figure out a way to improve our workflow and eventually, the quality of translations. Please don't misunderstand us, we don't want to ask for impossible things, and I perfectly understand that locking is probably not the best solution today.

Could maybe a simple alert at the top of a freshly imported translation be easier to implement? something like:
"Attention: this translation was automatically imported from an upstream project. Please check with [translation team or coordinator] before starting any translations, since they maybe overwritten quickly!"

У пон, 31. 08 2009. у 06:27 +0000, Séverin Lemaignan пише:
> Danilo, we are trying to figure out a way to improve our workflow and
> eventually, the quality of translations. Please don't misunderstand
> us, we don't want to ask for impossible things, and I perfectly
> understand that locking is probably not the best solution today.

Right, and I do agree we should fix the problem you are experiencing.

> Could maybe a simple alert at the top of a freshly imported
> translation be easier to implement? something like:
> "Attention: this translation was automatically imported from an
> upstream project. Please check with [translation team or coordinator]
> before starting any translations, since they maybe overwritten
> quickly!"

Unfortunately, that's still impossible, because we still don't know if
it was imported from an upstream project or if it is a modification from
a package.

Basically, the core problem is that Launchpad doesn't know if something
is "upstream": it only sees "packaged" translations which is what Ubuntu
provides.

Ideally, I'd envision this working as follows:

 * Ubuntu package builds provide us with both upstream template and an
Ubuntu modified template
 * Launchpad figures out ubuntu-specific messages from that, and marks
them appropriately
 * Launchpad does daily imports of upstream translations
 * We carefully enable message sharing between upstream translations and
Ubuntu translations

With this, there would be no locking needed, since all upstream
translations would be reflected in Launchpad's Ubuntu section every day,
and you'd be able to go over only Ubuntu specifics to make sure they are
translated.

Though, just importing all upstream translations daily and enabling
message sharing between projects and distributions in Launchpad should
solve the 'we want locking' problem. Having a separation between
Ubuntu-only strings would be a useful addition on top of that.

Considering how Launchpad is now open source, if you want to help make
this happen, I'd be happy to lend a hand and discuss further plans on
what we can do which I won't mark as 'won't fix' :).

:-)

On Mon, Aug 31, 2009 at 13:56, Данило Шеган<email address hidden> wrote:
> У пон, 31. 08 2009. у 06:27 +0000, Séverin Lemaignan пише:
>> Danilo, we are trying to figure out a way to improve our workflow and
>> eventually, the quality of translations. Please don't misunderstand
>> us, we don't want to ask for impossible things, and I perfectly
>> understand that locking is probably not the best solution today.
>
> Right, and I do agree we should fix the problem you are experiencing.
>
>> Could maybe a simple alert at the top of a freshly imported
>> translation be easier to implement? something like:
>> "Attention: this translation was automatically imported from an
>> upstream project. Please check with [translation team or coordinator]
>> before starting any translations, since they maybe overwritten
>> quickly!"
>
> Unfortunately, that's still impossible, because we still don't know if
> it was imported from an upstream project or if it is a modification from
> a package.
>
> Basically, the core problem is that Launchpad doesn't know if something
> is "upstream": it only sees "packaged" translations which is what Ubuntu
> provides.
>
> Ideally, I'd envision this working as follows:
>
>  * Ubuntu package builds provide us with both upstream template and an
> Ubuntu modified template
>  * Launchpad figures out ubuntu-specific messages from that, and marks
> them appropriately
>  * Launchpad does daily imports of upstream translations
>  * We carefully enable message sharing between upstream translations and
> Ubuntu translations
>
> With this, there would be no locking needed, since all upstream
> translations would be reflected in Launchpad's Ubuntu section every day,
> and you'd be able to go over only Ubuntu specifics to make sure they are
> translated.
>
> Though, just importing all upstream translations daily and enabling
> message sharing between projects and distributions in Launchpad should
> solve the 'we want locking' problem.  Having a separation between
> Ubuntu-only strings would be a useful addition on top of that.
>
> Considering how Launchpad is now open source, if you want to help make
> this happen, I'd be happy to lend a hand and discuss further plans on
> what we can do which I won't mark as 'won't fix' :).
>
> --
> Add the ability to lock translations managed by upstream teams
> https://bugs.launchpad.net/bugs/421441
> You received this bug notification because you are a direct subscriber
> of the bug.
>