Set the default translations permissions to Structured, assigned to Launchpad Translators
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
Right now, when setting up a project for translations, there is a step
reserved for setting its translation permissions. It is a form with 3
combo boxes, with the defaults between square brackets:
* Translation group [(no value)]
* Translation permissions policy [Open]
* Translation focus [(no value)]
This report is concerned with the two first items (translation group and
translation permissions policy) and their default values: I'd like to
propose to make them:
* Translation group [Launchpad Translators]
* Translation permissions policy [Structured]
Rationale
---------
In my personal experience, most maintainers or developers are not
involved in the translation process and are not familiar with concepts
such as translation groups or translation permissions. They
understandably only want to make their project translatable and make it
easier for people to do so.
Even if there is good documentation, accessible from the same settings
form, the step of setting permissions tends to be forgotten (it is not a
requirement to enable translations for a project) or left at its
defaults, which has effectively the same end result.
This means that very often permissions for projects in Launchpad are set
to Open.
I will not discuss here the need for Open permissions. I think it is
good that we have them and that we give the option to developers that
knowingly choose to use them, although I personally always encourage the
use of Restricted or Structured when translation quality is a concern.
We've also got very good documentation on the pros and cons of each
permission model, so that developers can make a good decision based on
knowledge:
https:/
I believe changing the defaults to be as proposed would be a major
improvement in the case where develpers simply don't think about
translations permissions, or don't know anything about translations
quality, in which cases we might as well assist them in making the right
choices.
Note that while we want to improve quality, we don't want to end up with
a too restrictive setup: we still want to lower the barrier for
contributions, which is why I'm suggesting to use Structured rather than
Restricted. As the Launchpad Translators group grows, there will be more
and more language teams added, allowing for effectively more translation
QA.
Some of the benefits of this proposal:
* It would alleviate the bad press Launchpad Translations get for
* It would give more visibility to the Launchpad Translators
group, and promote its growth
* It would effectively improve the quality of translations: a
benefit for users getting the end result and for translators,
who would not have to play catch with fixing translations
* It is a trivial fix - I assume :)
In talks with Danilo in the past, the proposal was rather to fix this
properly making it easier to set up translations for a project as a
whole, and one concern was the interaction logic with the other options
in the combo boxes: what happens when someone changes one option, should
the other options also change to have sane choices? I.e. choosing a
group and then Open permissions is not useful: Open will override the
review role of the translations group.
After another conversation with translators today, I believe at this
point just addressing a fix to the defaults would provide instant
benefits, whereas the other concerns can be addressed whenever there is
a UI redesign.
affects rosetta
--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanel
www.identi.
Changed in rosetta: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in launchpad: | |
importance: | Medium → Low |
Considering the potential impact on localization quality, I cannot say that I agree with the lowering of the importance field.