Matthew East wrote: > On Thu, Oct 9, 2008 at 11:19 AM, Jeroen Vermeulen <[EMAIL PROTECTED]> wrote: >> It largely depends on how much of the overall translation work the pending >> imports will cover. The lower the ratio, the more sense it makes to >> prioritize the templates. > > Ok, I don't really understand this, because I would have thought that > all new strings are worth having in the interface asap before po > files, on the assumption that merging the outstanding pot files in the > queue probably wouldn't take that long (how many imports does > Launchpad get through per day?)
At the moment we're importing about 2k-5k files per day, although variability is huge. Most of the remaining files are OpenOffice updates or newer uploads. The problem with importing templates long before their uploaded translations is the risk of redundant translation work. It might sound like the sort of problem you'd like to have, but actually we've found that it generates some very painful problem patterns: 1. Translators do lots of work, but their suggestions are not accepted because the messages they translated also turn out to be covered by the upstream imports. So they find back nothing of their own work in the end result and feel rightfully frustrated. 2. Some of those translators then mistakenly identify not being a member of an Ubuntu translation team as the root problem, and sometimes file membership applications as Rosetta questions. 3. Translations are accepted and then override the upstream ones that are imported later, leading to complaints about unwarranted "forking" of the translations, bug reports, demands that we block this or remove that, and so on. I've even had someone from a translation team ask me: "who reviews our translations and decides what goes into Ubuntu?" 4. People experiencing this find it hard to get to the places where their effort is going to be most useful, especially without good team coordination, and come up with ideas for fixing this in the UI. They are often good ideas, often overlapping or conflicting ones, never perfect solutions. And so far we never quite get around to choosing ones and implementing them. A lot of the fallout ends up with us, the application developers, even when some of them are at least partly matters of Ubuntu community organisation. We spend a lot of time on this, despite various policies and practices aimed at minimizing them, because until recently the Ubuntu division did not have anyone at all to coordinate the translation effort. That's been partly addressed now, in the Intrepid cycle, but the new role is still gearing up. We do make improvements on the engineering side to help address these problems: Ubuntu translations to language that have nobody to manage them no longer solicit suggestions. We no longer need to take Launchpad offline to initialize translations for a new release. A lot of outdated or misleading UI text about translation teams has been cleaned up and documentation has been rewritten. Also, as of next month, upstream translations will start replacing ones that are translated only in Launchpad but not upstream. (This would have rolled out last night, but we were busy dealing with Ubuntu imports operationally). Message-sharing will break down the walls between translations of different Ubuntu releases, eliminating much duplication of effort and taking a huge amount of pain out of translation openings, but it's a major effort that we complete one step at a time. Given the amount of pain it can cause, I think moving templates ahead of translations as general practice is replacing one problem with another. Our current plans are to open translations for new Ubuntu series much more aggressively, building on the organisational changes being made on the Ubuntu side; continue improving documentation thanks to the unrelenting efforts of Matthew Revell; and continue with these technical measures. A more precisely outlined procedure might still help. For instance, we might want to prioritize templates that have been Approved for a long time but which don't have any translations in the queue. One limitation there would be that the auto-approval process is already loading our script server more heavily than we'd like. Or we might want to show "careful, this translation has an import coming" warnings. The limitations there would be UI design, page rendering cost, and engineering time. Jeroen -- ubuntu-translators mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
