Hi Johannes, Today at 13:12, Johannes Schmid wrote:
> 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. Unfortunately, it's not the only one. I've heard similar complaints about at least SuSE. > 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. Searching for 'translating ubuntu' leads me to the following page: https://wiki.ubuntu.com/TranslatingUbuntu#head- 237425e48b4c2f6a6a7ef45204ac72183858ea2c What is said there is "Join the team you are interested in, but take care that it's more QA team than just a translation team. You don't need to join a team to translate Ubuntu, only to improve already existing translations." This might not be clear enough, so we will work on improving this further. However, I am pretty sure most people won't even hit this page, so I don't know what's the best solution to educate people. > 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. Agreed to an extent. However, we are not going to design something which stops people from being creative and patching entire set of translations. If they want technical aid to stop them from doing that by mistake (which is what's happening now most of the time), we'll provide that. > 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. Please re-read what I've said. I said 'consider upstream teams the only trustworthy source'. I wasn't at any time debating whether one should trust upstream teams, because that's considered a given. I was debating whether they are the only one (and I think they are not). > 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. I am not saying we need them. I just don't see a reason to design a tool to disallow it. > - 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. Afaik, Ubuntu is not that slow at all. The problem is that we give priority to corrections done in Launchpad, and we can easily reconsider this. > - 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. Right, I misunderstood you, but I see your point now. Such bugs should not go to upstream, but to Ubuntu bug tracker. However, similar things happen for any patched package, and we just learned to live with it. It's not because anybody is recommending people to do that (Ubuntu recommends using Launchpad for any bug reports), it's because they are doing what they feel is right. Just closing the bug should be fine, because it's indeed a bug in Ubuntu, not in your translation. Filing it in Launchpad would be an extra courtesy which is by no means required (i.e. nobody expects GNOME translators to work on Ubuntu if they are not interested). > 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). You missed my point. It's impossible to lock GNOME translations exclusively at the moment, and fixing that will take a huge amount of work. We can only lock entire language, and that would make Launchpad Translations completely unusable for translating Ubuntu. So, I see one possible quick way out of this dead end. We can give higher priority to implement option of allowing upstream translations to override Launchpad provided ones (this is one of the things I mentioned in my first comment). That would mean that any new package uploads in Ubuntu would refresh current translations with upstream provided ones, if a translation team chooses to use that option. However, that can happen next month at the earliest (and I am not making any commitment yet, this has to be discussed within the team), because, even if a simple change, it will involve changes to the core piece of our code, thus needing a lot of testing. Doing this will, of course, limit our time on other interesting things we can work on, but I am sure GNOME as an upstream doesn't really care about that. -- 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
