Hi Danilo! (I try to answer by mail as I guess Launchpad might support this...)
Am Dienstag, den 05.02.2008, 14:40 +0000 schrieb Данило Шеган: > 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. I think it's not very clear apart that only few people will be reading it anyway. Sorry, but I can't say where a good place to add this info is as I never used launchpad for translations. > 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. IMHO, people should do their creative work upstream or at least push it upstream. Though I don't like the work "creative" in this context, as there are only good or bad translations. > I am not saying we need them. I just don't see a reason to design a > tool to disallow it. Why allow something where there is no need? > 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. I don't know how the Ubuntu system works but it still ships anjuta 2.2.0 while the upstream version is 2.2.3. But this is going to be off-topic. (But see recent posts on planet.gnome.org) > 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. Would this be language-wide or could you implement this based on package sets? Because I guess no language will be willing to check this as a global option but rather for good-maintained package-sets (GNOME/KDE/freedesktop). > 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. I think you are wrong here as most people really take care on the end-user. I cannot speak for GNOME (not even for gnome-18n, you are the spokesman ;-) but there are lots of interesting things I would like to see in Ubuntu/launchpad. Anyway, lets consider this won't be in place for hardy (= GNOME 2.22). That's no problem as most of the big problems could be solved by team-reorganizations. But would it be possible to to implement the "overwrite" policy (instead of a "lock" policy) for Hardy + 1 (= GNOME 2.24)? Personally I think that would be a reasonable time-frame for testing, getting feedback, discussing on GUADEC, etc. Regards, Johannes -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
