Hi Peter, У уто, 02. 02 2010. у 15:01 +0000, Peter Clifton пише: > 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. You can still set up a git import into a Bazaar branch and make use of the integration that way. However, this still works only for a single branch at the moment. > 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'd say it's a tension between how you deal with translations and how you deal with your releases. Usually, if you want a parallel installable library, each of those versions should have a different translation. In Launchpad, you would represent this with different "series" (eg. "trunk", "3.8" and "3.6"). Translations for a release can happen after the actual release, and Launchpad is designed to allow for it—and ideally, you'd rollout updated "old" releases with latest translations. What you are probably doing is just replacing one release in LP with a new one, while disallowing any more translations for an older release, even though you are planning on having it parallel installable. > 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. "Template" name is the common pattern to define if one template should be sharing translations or not. I understand your reasons for using "versioned" template names, but that's exactly what causes this problem. Our multi-series support works on the assumption that template names in Launchpad will be identical across different series, and that you are using Launchpad support for series. I.e. if you had a set up like: * https://translations.launchpad.net/geda/3.8/+pots/libgeda * https://translations.launchpad.net/geda/3.6/+pots/libgeda * https://translations.launchpad.net/geda/3.5/+pots/libgeda all translations would have been shared automatically, and the only thing you'd need to upload for a new release series would be a new POT file (all translations would have been reused with correct metadata on same strings). The requirement on the Launchpad level to achieve this is to use separate series (i.e. you currently only have "trunk" and "stable-1.6"), and use the same "template name" (but this is a Launchpad template name; we use gettext terminology and call a base name of a filename a "translation domain": that's "libgeda38"). Since we require manual approval (due to reasons previously explained), whoever did the approval approved your templates under different LP template names simply because version numbers in them indicate that you want that. Still, you'd have to use separate project series in LP, because that's how LP is organised. > 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. Slightly better approach is to download translations from the old template and re-upload them to the new one: it won't keep all the meta data because PO files can't hold it (they only have Last-Translator for the entire PO file). Whether what happens in LP with suggestions today is simply a design decision: we need to record who takes responsibility of activating this particular translation in this particular project, and we just don't have the ability to record all the interesting meta data. It's probably not a bad idea to fix it. > 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? If you don't want to make use of the Launchpad built-in translations sharing capability, there's stuff you can do. With the latest release, you can go to a page https://translations.launchpad.net/geda/stable-1.6/+pots/libgeda38/+edit and change the path of the template to a new path that your new upload is going to be. For changing the template name, you'll have to ask Launchpad Translations admins, but it's relatively quick and easy job for us if it's not conflicting anything (it is conflicting if needs to enter an existing "sharing" template set). Just ask on https://answers.launchpad.net/rosetta for any help or to speed up approval (it's so much quicker when we know someone is actively interested and we can get responses quicker). Also, you can sometimes help with the approval as well: if your file is in the import queue, since recently (~1 week ago) you can modify the path auto-approver expects to find it under yourself on the above page. Just enter the path/filename you used in your last upload, and the next run (which might still take a few hours) will auto-approve it. > 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? One way to do it yourself is to download PO files and use "msgmerge" and "msgcat" from GNU gettext tools to merge them. They are not simple to use and require a lot of understanding. With careful planning, you should be able to execute whatever policy you want. I've suggested above how you can avoid it in the future. > 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. Exactly :) > 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? Not yet, at least not at the moment. Though, our plan is to work on that in the next few months, and proper use of translation domains and series is going to be essential for automatic re-use. > > * 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. Today we can only provide this functionality using translation groups and translation permissions. If you want to do it, https://answers.launchpad.net/rosetta is a good place to request it at (so we make use of LP-built-in identification :). > > 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. It's UI available only to 'rosetta-admins' team and ubuntu-translations-coordinators team for Ubuntu. Not all people in the team do template approval. > (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). Right, it's an acknowledged problem that will take a while to fix. > > 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. History is interesting in that area (both Launchpad and Bazaar were funded by the same company ;), though I do point you at our existing git import system. You can get a git branch imported into Launchpad as a bazaar branch (bazaar branch metadata is technically a super-set of git metadata, or at least that's what I overheard from some bazaar experts :), and then use that to get translations imported. > > 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. Yeah, and we should be supporting imports from git, svn, cvs and mercurial branches as well. Cheers, Danilo
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)