Hi Daniel! First, I never intended to say that you would want to harm any project/translation by purpose. But as you can see from the reply of 9 translation teams, this is a real practical problem. And Ubuntu is the only of various distributions that causes such problems though it's of course also the most widespread one.
In detail: - 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). Please fix this ASAP (and the hard way as we dicussed yesterday on IRC). And it would also be nice to point people to the upstream teams because otherwise they will never know about their existance. It's usually better to help upstream in case you don't do Ubuntu-specific work. People SHOULD know that. - 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). This is something the different translation teams should take care of. Anyway, I don't like that Ubuntu makes it's own policies here. Upstream project have usually though very long about certain terms and if there is a difference between the KDE and the GNOME policy it should be resolved between those and not in Ubuntu. - 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. I know that there are teams where this works well (hardly heard of problems in gnome-de for example). Anyway, no to trust upstream translations is very unfair. I doubt that there are many places where the upstream translation of a string is significantly worse than the launchpad one. So, I still do not understand why you would need any "creative translation work". It's good to extend exisiting translations but no use to change them other than in an Ubuntu-specific way. - 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. Well, that's your problem usually. GNOME does lots of stable releases to bring things inside tarballs but Ubuntu is sometimes slow to package those. And you have so many patches in your packages that it wouldn't harm if you push some upstream (svn) changes downstream. - Upstream teams get bug reports about strings that are correct upstream but have been changed in launchpad 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://translations.edge.launchpad.net/ubuntu/hardy/+lang/de and you'll notice the column "Changed" which contains the number of messages changed in LP from a package (usually upstream, but technically not, which is why we can't detect Ubuntu-only strings), and you can click on a number to see all of them. I think you did not understand me. It's not the problem that you get bugs on our faults but GNOME gets bugs about Launchpad translation errors that either don't exist upstream or have been fixed already. It's impossible for an upstream translator to know the Launchpad translation and a such he will ingore/close the report and will most likely be too lazy to file it in lauchpad. Of course I know that you as Canonical have a big interest in bringing Launchpad forward and all your blueprints look very nice. Anyway, they do not solve the current problems that Launchpad first created. It is the wrong way to first create new problems and then to say that those will be fixed "one day". So many people would really prefer if you do your homework and better lock translations in between even if it will mean that Launchpad won't be of much use for GNOME translation for some period of time. At least that would force you to put effort in fixing these things. (Also read Olav's post on gnome-i18n). -- Lock GNOME upstream translations https://bugs.launchpad.net/bugs/188907 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
