On Mon, 2010-02-01 at 00:08 +0000, Danilo Šegan wrote: > Hi Peter, > > У нед, 31. 01 2010. у 12:20 +0000, Peter Clifton пише: > > > Having to wait hours (for the automatic review), or days - if it > > requires manual approval is a real strain on my productivity, and > > motivates me to stop using Rosetta for translations all together. > > Using Bazaar integration (importing templates directly from your bzr > code branches) should avoid the need for manual template approval. If > you are not introducing new templates, keeping the same directory and > filename structure should help get them all through automatic approval > every time. We're using git upstream, so Bazaar integration would not work for us. I guess in time, Launchpad may grow support for other VCS, and at that point we could switch to a more integrated flow. I think there are some technical questions I need to ask. Upstream (thanks mostly to Debian's requirement of co-installing library versions), our translation domain is $libraryname$soversion_major. E.g. "libgeda38", being the latest. This provides the ability to co-install library versions. It appears to cause a problem in Launchpad. This is partly our own making - having been rather bad at extracting and upstreaming translations from Launchpad. I'm now faced with obsolete templates and translations in Launchpad, libgeda33, libgeda35 and libgeda36. When I upload libgeda38 to the stable-1.6 series, none of the translation work contributed for the other libgeda* versions is automatically imported, despite the majority of the strings being identical. I can create a new language, and be offered the correct suggestions (from the other libgeda* templates), but this is not automatic - and appears to throw away meta-data such as who put the work into doing the translation. Is there some way (for an admin?) to bulk copy one translation template and translations to form the basis of another? I figured that copying one of the old templates to form the basis of the new, then uploading the new upstream template on top - would preserve any existing launchpad translations? Given we've got into the awful situation of having un-merged work in 3 templates, do you know of any tools to merge these and allow us to choose a policy to resolve conflicts? I suspect now, that it might have been wiser to split up the translation by series on Launchpad, but keep the template name as "libgeda" without any version suffix. Do translations from our gEDA project on Launchpad get used to form translation packs for Ubuntu (including the gEDA software)? If they do - do we need to ensure the translation domains match that used upstream? > > I'd appreciate some insight into the issues which translations are > > reviewed for, and why I can't do it myself. [snip] > * A project which has translations happening elsewhere shouldn't be > registered in Launchpad as well (or people would be confused) We fall into that last category, for a handful of languages where we have a history of upstream maintainers committing translations directly. I was thinking of requesting a translation group where we could say "no", to translations for "de", "es", "nl", as these are managed upstream. I wondered about adding a note to the translation page to this effect, but I don't think this is possible. > At the moment, we feel that everybody would be better off with the > approach of "letting everything in, clean-up later if needed". And, > some of these things should be detected automatically (eg. heuristically > for non-English in base messages). However, the approval process is > still confusing enough that even experienced i18n people get it wrong > sometimes. And the tools to clean up afterwards are non-existent. Sounds like a good reason to keep me out! I'm not experienced in this regard! I couldn't figure out if the approval process was related to an admin issuing commands / manipulating the database directly on a Canonical server, or whether it related to some UI in Launchpad which you only see if a member of the appropriate privilege group. (One of the things I find somewhat opaque in Launchpad - is how the privileges to edit certain things work. As a project admin, it would appear that I see more options than a general user - so have had (in the past) confusing exchanges where I was asking someone to visit a URL which only I had access to). > We've made a small step forward with bzr-integration, so I suggest you > use that for a faster turnaround time. As mentioned above, unfortunately we can't do this - at least, not without maintaining a "fake" bzr repository to work with translations. I don't know bzr, so it is unfair to knock it - but I don't see anything advertised about it that "git" (the one true VCS) can't do! I guess Launchpad had to choose "something" to work with though. > Auto-approver is also slow because it has to go over all files that need > reviewing over and over again until they are either approved or removed > from the queue. And it's a two-stage process (first it tries to > auto-approve a template, and when that's done, it auto-approves > translations against that template in the next run). Again, this is > historical. Ok - just sheer work-load on the servers then. > These are all things that we'd love to improve and/or see improved. > However, our time is severely limited. But, Launchpad is open source so > if you want to take on any of these issues, come talk to us on > #launchpad-dev on FreeNode IRC or start by visiting > https://dev.launchpad.net/. I can relate to the time issue. Perhaps I'll have a dig into it at some point to learn more about how the system works. I don't expect I'll get into coding though. I'd love to see some mechanism of tying translation updates on Launchpad to an auto-commit process into our branches. I guess this is along the lines of how the bzr integration works for those using it. Thanks for your detailed responses. Best regards, Peter C.
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)