Launchpad messing with the translaions?

[Khaled Hosny]

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.

> > > 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.

Regards,
 Khaled

-- 
 Khaled Hosny
 Arabic localiser and member of Arabeyes.org team
 Free font developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-translators/attachments/20100318/d185c42a/attachment.sig>