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
signature.asc
Description: Digital signature
-- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
