© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
Hi Johannes, Daniel, Арангел. We are aware of the position of upstream teams (not surprisinly, since I am involved in "one" myself :), but there are many problems which are technicaly not trivial.
Let me go through Johannes' points.
- Downstream translators often don't know about policies of the upstream language teams and many teams have a very strict review system
This one is true, but not really a problem of Launchpad as a tool. It's a communication problem: translations in Launchpad are sometimes too easy, and potential translators and team coordinators don't bother with actually establishing policies. Until Launchpad gets AI, it's just a PO editing tool like any other. We've got privilege system in place, but problems arise if people misuse it (as they have done numerous times, allowing everybody into translation teams).
Also, there's another reason. Many different localisation projects for the same language have differing terminology. For example, I know Serbian GNOME and KDE translation teams have different terminology. I see no reason for Ubuntu Serbian l10n team not to unify these translations and make them consistent accross Ubuntu. Yeah, I'd prefer it if they've used GNOME translations because that's where I am coming from, but I'd still prefer consistency over insisting on the "Serbian GNOME terminology". So, one important point here is that this is not a translation of GNOME, it is a translation of GNOME in Ubuntu, which is not exactly the same piece of software (only slightly changed, compared to relative size of GNOME, but changed nevertheless).
Now, I understand that in practice we've more often than not came into a situation where this technical ability has allowed translations of subpar quality to enter Launchpad and Ubuntu. That has happened a lot in the past because of the communication issues, but should happen less nowadays.
So, we're confronted with two options: consider upstream translation teams the only trustworthy source of translations (basically disallowing the option of doing any creative translation work in Launchpad, across entire sphere of Ubuntu software), or improve the trustworthiness of current Launchpad translators. We have so far decided to work on enabling better translator education in Launchpad through review and changed-in-LP workflows. However, Launchpad itself still doesn't provide enough means of communications between translators, and there's nothing that can replace communication. Launchpad is still a tool, and as such, it can't replace the communication needed between people. As a proof of that, I can point you at teams which are handling this process fairly well.
In practice, I am completely aware that you are right: majority of downstream translators are unaware of the policies upstream teams have, nor do they have their own policies. That's why we are considering different options for solving this, and that's why we've added the changed-in-LP filter and easy reversion process (and are looking into implementing reversion of entire PO file at once: https:/
Another option we are considering is locking a certain language in Ubuntu to new translations only. However, this still has a problem of duplicate work. Technically, at the moment, we are unable to find out in Launchpad Translations if certain messages are exclusive to Ubuntu. Solving that problem will take a while, and as soon we are able to do that, I am sure we'd be happy to add "lock to Ubuntu-provided messages only".
Also, I am pretty confident that an easy fix for many translation teams would be a simple option: make packaged translations automatically override LP-provided translations. However, that might also remove bug fixes, so it's hard to enable across entire Launchpad right now. I know you want bug fixes to happen upstream first, but you should take into account that upstream bug fixes don't get rolled out into tarballs immediately (or, just tell me how many times have you missed a GNOME release deadline by a day? :), and Ubuntu should have the power to fix these bugs for their own GNOME packages.
- Upstream teams get bug reports about strings that are correct upstream but have been changed in launchpad
If you believe upstream teams would be interested, we can make automatic bug reports into eg. GNOME Bugzilla. I'd have to check with our Bugs development guys if we can make this an easy one, and we can further discuss what should actually be reported (i.e. what level of change, how often to check for new fixes or do it live?). I am not sure at what level is GNOME Bugzilla xml-rpc API right now, but if we agree with you guys to use that, we'd be happy to work on it.
I know it's not yet trivial for upstreams to find out about problems in translations as fixed in Ubuntu, but your Ubuntu teams should have it much easier. We've recently added a listing of changed-in-LP messages on the global language overview page. Check eg. https:/
- Duplicate work for translators
Indeed, this is one of our major problems. We are looking into solving this in the short term (next 6 months) through different means, and I hope this functionality might enable us to also find the messages specific to Ubuntu (though, it's not an original goal for this). At the moment, the current plan is to remove duplication of work inside different Ubuntu releases, but it will technically also solve the problem of duplication between upstreams and Launchpad, if we create a right set-up.
- Importing stuff from launchpad (which is not easy anyway) becomes even more difficult when strings have to be merged.
It's actually not impossible, but would require playing with msg* tools a bit. You can actually give preference to any of the translations (eg. upstream or LP) with a bit of creative combining of tools. However, we are aware that we should not ask people to do that, thus we've got plans to improve this. Look at:
https:/
https:/
https:/
https:/
These are all designed to make merging process as smooth as possible for upstreams. We want to make it automatable as well, but that's not near term material.
So, I want to asure you that you have someone (well, everybody :) on your side in Launchpad Translations development, and that we are looking into problems you are experiencing, and we want to solve them. Lot of the previous development (like the mentioned changed-in-LP, or automatic translator-credits filling which we did only because some Ubuntu translators were removing credits for your work) has been done only to improve upstream translators' experience of Launchpad and Ubuntu. And we are continuing that work steadily over time, but it's not happening overnight.
Since we can't accept the simple solution of disallowing Ubuntu translations through Launchpad (which is basically what you are suggesting), we are looking at other options of improving experience for both Launchpad and upstream translators. I've included in this comment many ideas we have, linked some of the blueprints we plan to implement, and mentioned stuff we already did—but we are still looking for suggestions.
And we are not doing any harm on purpose. We want Launchpad to be equally useful to everybody, begginers and advanced translators alike. If we haven't done something already, it's probably because it's not really easy at the moment.