Launchpad messing with the translaions?

[David Planella]

Hi Khaled,

El dj 18 de 03 de 2010 a les 14:21 +0200, en/na Khaled Hosny va
escriure:
> On Thu, Mar 18, 2010 at 09:16:35AM +0100, David Planella wrote:
> > Hi Khaled,
> > 
> > El dj 18 de 03 de 2010 a les 00:05 +0200, en/na Khaled Hosny va
> > escriure:
> > > On Tue, Mar 16, 2010 at 01:08:37PM +0100, David Planella wrote:
> > > > Hi Khaled
> > > > 
> > > > El dt 16 de 03 de 2010 a les 13:21 +0200, en/na Khaled Hosny va
> > > > escriure:
> > > > > While working on Lucid translation, I'm seeing many weird things (that
> > > > > is, above the usual launchpad weirdness level).
> > > > > 
> > > > > * indicator-session containing translations we didn't approve, I've bee
> > > > >   told that those came from the 'upstream' launchpad project, and that I
> > > > >   should translate it there. But, the "upstream" has no translations
> > > > >   available!
> > > > >   https://translations.launchpad.net/indicator-session
> > > > 
> > > > I cannot actually remember it right now, but it could have been that the
> > > > upstream project was open for translations for a while, and that the
> > > > permissions were set to Open. That might have been the problem.
> > > > 
> > > > We try hard to let developers know about translation permissions [1],
> > > > and recommend using Restricted or Structured permissions, but sometimes
> > > > projects are still set up for Open translations. Whenever I see that, I
> > > > recommend developers to change it, and I encourage translators to do it
> > > > as well.
> > > 
> > > The problem is that one can never know about such things and we are very
> > > likely to ship with broken translation, I don't go and re-review the
> > > already reviewed translation for each Ubuntu release. Right now, I don't
> > > know how many translations have been broken this way, and a full review
> > > is not an option.
> > > 
> > 
> > This issue only affected indicator-session, as far as I know. I've
> > talked with Sebastien, Ted Gould and Kyle, and here's what happened:
> > 
> > As you know, Ubuntu is also used in commercial projects, which use the
> > same (or modified) packages as the free Ubuntu distribution. These
> > commercial projects have got generally different schedules than Ubuntu,
> > and sometimes translations must be completed by a certain date, a
> > schedule that cannot be forced upon voluntary translators. In those
> > cases, translations are completed privately and then released in an
> > Ubuntu package and given to Ubuntu Translators for them to modify and
> > correct if necessary.
> > 
> > That's what we did for example with the Ubuntu Netbook Remix (UNR)
> > translations a few months back, as was explained on the list back then.
> > 
> > Also as learned back then, Ubuntu translations constitute sometimes
> > important fixes, so these are preferred over the private translations.
> > Once translations of a given package have been opened to the community,
> > the idea is to export the Ubuntu translations and merge them back into
> > the upstream project in Launchpad (which we recommend in these cases not
> > to expose translations, in order to avoid two sources of translation),
> > giving priority to the Ubuntu strings.
> > 
> > That is the background. The particular problem with indicator-session
> > was that the upstream package contained some private or old translations
> > in its trunk, while translation activity in the Ubuntu source package
> > was happening at the same time. Due to a mistake, the step of exporting
> > Ubuntu translations and committing them to the package's trunk was
> > missed. When uploading a new version of the package, as Launchpad now
> > prefers upstream translation over Ubuntu ones [1], unless explicitly
> > changed, the imported translations overwrote the ones from the Ubuntu
> > package.
> > 
> > While we'll make sure that this does not happen again, I'd like to ask
> > translators to review the indicator-session strings [2] to make sure
> > they're ok in their language.
> 
> Thanks for the explanation.
> 
> As a side note, wouldn't it be more appropriate to approach the
> community translators first for such paid work, so every one wins; the
> community gets its translation completed and the "commercial" projects
> get a consistent with upstream translation that is not going to be
> overridden.
> 

That's a very good point actually, and it would mostly solve the problem
with synchronisation between the upstream project and the distro
translations.

However, there are some other aspects to consider with that approach:

      * Canonical creates Ubuntu variants for clients for which
        translations need to be completed before the variant is
        released. Generally these are open source on release, but
        nonetheless, there is a need to translate them previously. An
        option might be to expose the translations only, but Ubuntu
        translators might choose not to translate something for which
        the code is not yet available and which they cannot test their
        translations with. 
      * If deadlines are tight, it is much simpler to work with a single
        private translation company to coordinate the work.

In any case, as noted in the UNR thread a few months back, we rely that
the work Ubuntu translators do might constitute fixes and improvements,
so the idea is to always upstream the changes from Ubuntu. That is,
manually export the Ubuntu translations and commit them in the upstream
project.

It's just that in this particular occasion with indicator-session it
didn't happen due to an oversight, so I apologise for any trouble
caused.

> > > > I'm not sure who recommended you to translate upstream, but I can
> > > > confirm what you already saw: indicator-session is only currently
> > > > translatable by Ubuntu Translators, and the upstream project is
> > > > currently not open for translation.
> > > 
> > > Sebastien Bacher, to him the aforementioned translations were
> > > attributed, suggested that when I approached him about the issue.
> > > 
> > > > > * too many of the fixed translations in update-manager, that we fixed in
> > > > >   earlier releases, were reverted to the old, buggy (i.e. causing
> > > > >   software crashes!) translations, the corrections are available as
> > > > >   suggestion though!
> > > > > 
> > > > 
> > > > I'm not sure what happened there. I know that Michael (mvo), the update
> > > > manager developer, exports translations from Launchpad from time to
> > > > time, but the upstream update-manager has no translation template
> > > > exposed.
> > > > 
> > > > You might already have corrected the invalid translations, but could you
> > > > point us to them (or just paste here the correct and incorrect ones), so
> > > > that it is possible to track this and we can submit a bug if necessary?
> > > 
> > > Here are some examples:
> > > https://translations.launchpad.net/ubuntu/lucid/+source/update-manager/+pots/update-manager/ar/242/+translate
> > > https://translations.launchpad.net/ubuntu/lucid/+source/update-manager/+pots/update-manager/ar/243/+translate
> > > 
> > > The 'packaged' are the wrong ones (will crash the application) and were
> > > originally fixed several months ago.
> > > 
> > 
> > Right, thanks for the new details. I still haven't found out what
> > happened with them, but I'll investigate further.
> > 
> > I've got a related question:
> > 
> > These are python-format strings using unnamed arguments (%s). If I
> > remember correctly, this forces on languages such as Arabic the use of
> > not so grammatically correct translations for the first plural forms
> > (you need to specify the %s arguments in all cases). Using named
> > arguments (%s(days)) would allow you dropping the arguments and provide
> > more correct translations. I could propose changing that string to use
> > named arguments.
> > 
> > Would that change be useful to you and other languages facing the same
> > problem and do you think it would justify a string freeze exception?
> 
> For now, we use a kind of hack; %0.s argument that don't expand to
> anything but acts as a placeholder keeping python happy.
> 
> So, I say, we just need to list all affected strings and ask translators
> fix it this way (assuming that hack is safe), and do a proper fix next
> cycle.

Ok, although this might affect quite a lot of Python packages. I'm not
sure it is possible to list all of the strings, and I was thinking only
of the particular ones in update-manager.

Regarding your fix, I've done a quick test, and while it works (Python
does not complain), I noticed that it will only work with %s arguments.
For unnamed numeric arguments (e.g. %d) you'll probably need to find
another workaround for formatting, if that's possible.

Regards,
David.

-- 
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Això és una part d'un missatge signada digitalment
URL: <https://lists.ubuntu.com/archives/ubuntu-translators/attachments/20100318/ba2944a3/attachment.sig>