Re: Joining a translation team
On 04/26/2013 08:00 AM, Adeeb Nqo wrote: I want to get involved in translating Ubuntu to IsiXhosa (xh_ZA). I applied for membership on the Ubuntu Xhosa Translators team on launchpad on 2013-04-06. I haven't recieved a reply nor has my application been (dis)approved. You shouldn't need to apply for membership of that team just to get involved in translating. The way to get involved in translating is... just translate! The team's purpose is not just to translate, but also to review and enable translations that others contribute. You can still decide you want to join the team later, but that will be easier if you've done some translation work first. If the team is not reviewing translations at all, then there is cause for concern. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Help to upload PO faile
On 01/23/2013 04:06 PM, Sylvie Gallet wrote: Hi Talat, Maybe you should edit line #12: Last-Translator: FULL NAME EMAIL@ADDRESS\n and replace FULL NAME and EMAIL@ADDRESS with your real launchpad full name and your address. This is needed, but perhaps not enough. Maybe this is the immediate cause of the problem: Then you can go to the launchpad page where you downloaded toe .po and click on the upload link. Only members of the translation team get that link. If you're not a member, work with the translation team to get your translations uploaded. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Help to upload PO faile
On 01/23/2013 07:47 PM, Talat Noumonov wrote: Yes, u r both right, unfortunately I'm not translators team yet. Right now I sent request to Ubuntu translators coordinator request to add me to translators team This is not really an issue for the Ubuntu translations coordinators... I think you'll have more luck with the owners of the translation team for this specific language. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Question about automatic Import and export
On 2012-06-16 19:42, Francesco Fumanti wrote: Assuming, we modify a translation in a po file of Onboard in the source code repository, and somebody else changes a translation in the translation interface of Launchpad. How do I know, that the import triggered by our change in the source code repository does not overwrite the change in the translation interface, or that the export triggered by the change in the translation interface of launchpad does not overwrite our change in the source code repository? Does the import and export take such concurrent changes into account or does it blindly overwrite the one or the other? Disclaimer: it's been a while since I did any serious work on this, so I may get some things wrong. And it's complicated, so there's always things that can go wrong. That said, it seems to work out pretty well in practice. Here's what I think happens: The daily automatic export job will notice that there are concurrent changes, and just skip the export for that day. This doesn't quite cover all possible conflicts, but that's where the importer's conflict resolution comes in. If you take a PO file that was exported from Launchpad Translations, edit it offline, and then re-upload it, there will be a timestamp in the header saying when it was exported from Launchpad. If the importer sees that one of the translations has already changed in Launchpad since the file was exported, it will downgrade the file's translation of that message to a suggestion. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: [Launchpad-translators] New Launchpad rollout: please put translations for upstream projects on hold
On 2011-01-13 17:18, David Planella wrote: However, as a side effect and due to a migration script not being run in the Launchpad side we'd like to ask you to wait a bit to do new translations _for upstream projects in Launchpad_ until we can run this script again and make sure new translations during this time are not reverted to suggestions. It should take about a day to run the script, and after that you can keep translating as usual. We'll send a new notice when the run has finished. I just got word that the script has completed, and things should be back to normal. It's safe to translate again! We're sorry about the inconvenience. We hope you will find that you get a simpler, clearer, and less work-intensive translation application in return. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Reverting translations to packaged
David Planella wrote: In case we decide for the reverting, what happens with the plural forms? In slovenian, there are two different plural expressions and some time ago we decided to use just one in ubuntu. Upstream translations were adapted to fit in the ubuntu plural expression. What happens after reverting, will we get back the old non-consistent situation? I think Danilo, Henning or Jeroen will be able to better answer that question. As David says, nothing happens to the plural forms as such. You'd just be getting the upstream translations back and losing the ones made in Launchpad that didn't go upstream. Whether we'd be reverting to translations that are compatible with the plural forms as defined for the language is another matter. If the difference in plural forms is just one of ordering (e.g. one formula has forms 0, 1, 2 but the other has 1, 2, 0) but they are otherwise compatible, then Launchpad does intelligent remapping between the two orders. As Danilo mentioned, it would be technically possible, but the Launchpad Translations team cannot possibly cope with such fine-grained requests due to the big number of teams. For individual packages you can just use the 'Changed in Launchpad' filter -although I agree that depending on the team it can be tedious to do this manually if, let's say, a package has 1000 translations different from 'Packaged'. In any case, this should be a one-time effort, but again, I'll let the LP translations guys to answer this one. Acting only on listed packages shouldn't be much harder than doing an entire language. The real problem is managing database performance as we update or delete records on this scale. I don't think we have anything quite ready to use for this. And given some very unlucky timing planning-wise it seems unlikely that we'll be able to have something in place for the coming 2—3 months. I'll leave it to Danilo when he gets back in a week and a half to say whether we can take a shortcut. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Strange position of images in translation pages
Milo Casagrande wrote: don't know if it has been reported as a bug on Launchpad or if it is related to me using edge, but I'm experiencing some strange images positioning in the translation overview pages. Since a picture speaks more than a thousand words, I'll attach it here. Is it something already known? I believe it's a known problem, yes. Work in progress on the generic UI side of Launchpad. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations have become suggestions
Moritz Baumann wrote: Puzzling indeed! Do you know exactly when this was? We may be able to correlate it to something. the import of gnome-user-docs was done on April 11 or 12 and approximately one week later I noticed the problem. I'm not sure about the other templates, though. Since Danilo requested a link: https://translations.launchpad.net/ubuntu/jaunty/+source/gnome-user-docs/+pots/accessibility-guide/de/ This translation was indeed last imported early on April 12. Something weird must happened around that time, but we don't know what yet. All we really know is that our database replication lag suddenly jumped. Your problem may be related to this one: https://answers.launchpad.net/rosetta/+question/68169 Could you, or anyone who experiences similar problems and has detailed information about it (when, where, what if possible the text of the confirmation email) please add it there? For now unfortunately we don't have anything that points us in a specific direction of what may have happened. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations have become suggestions
Hello Moritz, Moritz Baumann wrote: 1. Other translations were imported (or selected by another translation team member) after you provided yours. No other member of the German team had worked on these templates. 2. If you did a published upload, then any non-published translations that Launchpad had for the same strings would remain selected, and the newly-imported ones would be taken as suggestions. Even if the string had not been translated before the imported translation is now shown as a suggestion. And after the import all new translations had (temporarily) been shown as the current translation, that's what puzzles me most. Puzzling indeed! Do you know exactly when this was? We may be able to correlate it to something. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations with bad formatting strings now disabled
André Gondim wrote: I am working to solve the Brazilian Translation, but I don't find the error at klaptopdaemon, what is wrong in this string: #: laptop_daemon.cpp:559 #, c-format msgid 1% left. msgid_plural %n percent left. msgstr[0] Restando 1%. msgstr[1] Restando %n%. These don't look like C-style format strings at all to me. If this were a C format string, each of these strings would be wrong. So I'm guessing this is some other formatting standard that ignores % if followed by a space, and prints a number for %n. So in this case, the bug is in the code or in the template (assuming it still says c-format) not in your translation. What is wrong at konversation.po in pt_BR po file? #: src/connectionmanager.cpp:212 msgid Trying to reconnect to %1 in %2 seconds. msgstr Tentando reconectar em %1 em %2 esgundos This again is not a C-style formatting string, but some other format. Maybe it was marked as c-format in the template when it should be using some other format flag. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: voting on a string
Kenneth Nielsen wrote: Changed the spelling error in the title so that it now is sign-off the way it should be, that means that it is now to new URL's https://blueprints.launchpad.net/rosetta/+spec/sign-off-on-translation https://wiki.ubuntu.com/SignOffOnTranslation Thank you. Be warned that we have a lot of engineering work to do, so it's probably going to be some time before this becomes a candidate for our priorities list! Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Translations with bad formatting strings now disabled
Hi all, This is about the msgids that were used as format strings, where some of the msgstrs had incompatible formatting directives, e.g. translating file not found as %s not found. We've just completed a full gettext check of all active Ubuntu releases. Any messages that failed gettext's format-string checks were disabled. In cases where the problem was only in a Launchpad-specific translation, we've reverted to the upstream translations. For Hardy, 1,780 messages were disabled and 239 ones from upstream re-enabled. In 26 cases the upstream message was different but also failed the check. For Intrepid, 1,520 messages were disabled and 376 ones from upstream re-enabled. In 30 cases the upstream message was different but also failed the check. For Jaunty, 1,506 messages were disabled and 299 ones from upstream enabled. In 26 cases the upstream message was different but also failed the check. The number of messages checked was about 2 million per Ubuntu release. These were the currently selected messages with the c-format flag (or equivalent for another language) enabled. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations with bad formatting strings now disabled
Adi Roiban wrote: Is there a report with these packages. Lately the Romanian team was using the Ubuntu language packs[1] to check them for errors and report them upstream[2]. Now, if Ubuntu language packs are clean I don't know how we can help the upstream projects. I'm glad you asked. :-) Since the script had to run on our production database to disable messages, I didn't want to burden it with this. Instead, I can run the same script on a read-only copy of the database just to check for upstream cases. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: voting on a string
henn...@ubuntu.com wrote: Hi all, currently there are no plans to implement something like this but it might be worth explaining the idea in a blueprint so that it won't get lost. Frankly I'm a bit worried that this would be spreading the translation effort too thin. The current process is: translator (any logged-in user) submits a suggestion, after which a member of the translation team checks whether it should go in. If you expect more people to sign off, that opens the door to lots of people working on the same fraction of strings without achieving as much as they would as reviewers. That's assuming those voters are aware enough of applicable terminology and style standards etc. to be reviewers. But if most aren't, then the voting is really only helpful for the cases that a good reviewer instantly recognizes as correct anyway. Finally, there's a technical issue with a cost trade-off: we have millions and millions of translated messages for every Ubuntu release, with large numbers of people involved. If this feature sees serious use, we'd have to store millions and millions of votes: person X already voted for translation Y. That will slow down the site--maybe so little that you wouldn't notice, or maybe so much that it annoys lots of people. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: errors in PO files from Ubuntu
Adi Roiban wrote: I'm using it for checking the status for Romanian team and I will generate them for other languages. It would be nice to have such a stats directly in LP (maybe when it will be open sourced). These may be useful to you when completed: https://blueprints.launchpad.net/rosetta/+spec/import-queue-failed-error-display The idea there is to add the failure output to the import queue entry, so anyone can see it. https://bugs.launchpad.net/rosetta/+bug/286359 This one is about emailing import errors for automatic Ubuntu imports to people more directly connected to the packages in question. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: How to revert to upstream translations
Milo Casagrande wrote: I just quote from last Danilo message regarding this aspect: Launchpad Translations has changed the translation precedence policy with the December release: now upstream (packaged) translations will be given more priority in specific cases. Yet, Launchpad Translations keeps the ability to override any specific upstream translation if so is desired. Thanks Milo for bringing this quote in. To be clear: 1. If the currently selected translation for a message in Launchpad is the one that was last imported from upstream, then that message will track upstream. So if a later import from upstream changes the translation, Launchpad will also use that new translation. This has always(1) been the case. 2. If the Ubuntu translation team has chosen to diverge from the upstream translation, then the translation in Launchpad overrides the upstream translation. It continues doing so until either the Ubuntu translation or upstream decides to use the same text as the other. That's why translation teams should do this only if the upstream translation is buggy, or requires an Ubuntu-specific translation different from the upstream one. Launchpad/Rosetta has no way of guessing the team's reasons. For the buggy case, of course the translation team would do well to report to upstream. 3. The situation Danilo is referring to is this one: upstream does not translate a particular message, but Launchpad does. Then, upstream does add a translation of its own for that message, and the new translation is imported. In this case Launchpad does guess the reason why it had a different translation than upstream: because upstream didn't have one. And so it switches to tracking the upstream translation in this case. It's this last part that's new(2). Jeroen (1) Well, I happen to know it wasn't the case during the late Pleistocean, for example, but grant me some artistic license here. (2) To put this in perspective: the late Pleistocean is very old. This feature came more sort of late 2008-ish. -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Launchpad Translators group
Milo Casagrande wrote: From: Adi Roiban [EMAIL PROTECTED] I have create the following blueprint thinking that at the next UDS we can discuss the relation of this new groups with the already well established Ubuntu Translators groups. https://blueprints.launchpad.net/rosetta/+spec/launchpad-translators-group Subscribed! ;) What do you think? It's a great idea to improve the opinion that outsiders could have about Launchpad and to attract new teams inside! Hopefully in this way more projects will let their translations under the Launchpad umbrella; I'm struggling to get some projects (not related to Ubuntu) under the Ubuntu Translators team, and it's not that easy... I think this is a great solution for that. The Ubuntu translation group should be for Ubuntu, but there's no reason why we can't have a reference implementation of a Launchpad translation group that people can come to by default. It may even inspire more translation groups and teams. I'd like to invite everyone here to the discussion about this at UDS. Let's make this work! Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations from the debian-installer package
David Planella wrote: What it boils down to is something that I feel has been always missing in the Ubuntu translation process, and is a team or an individual who acts as a coordinator between the translators and the developers. The That, to me, is the heart of the problem. The Ubuntu translation process as a whole needs to be managed by someone who is involved in Ubuntu on a full-time basis. In fact the Rosetta team has been pushing for the creation of this role since early this year, and Arne has for some time been fulfilling its technical aspects. A lot of this work fell to Carlos in the past, but I don't think it makes sense for the application developers to keep track in enough detail to coordinate the Ubuntu translation process. From our perspective, we'd much prefer to have more knowledgeable people manage the process and tell us what we can do *in the code* to facilitate their work. Besides distracting us from improving Launchpad Translations, the situation also meant that everyone depended much more on Carlos than anyone ever realized. His departure left a gaping hole--even more so on the Ubuntu side than on the Launchpad side. Usually this list has been used to this purpose, but obviously not all developers follow it. And even when using the bug tracker, you do not often know if the translation problem is due to the package, to Rosetta importation problems, to the langpack not having been updated, etc. At the moment, this is rather chaotic. Just a few examples in this release: new strings being added to the templates a day before the translation deadlines, without announcing them anywhere; important packages without translation templates being released also a few days before the translation deadlines, with the subsequent impossibility to have them localised before release; Rosetta's ever stalled import queue, etc. All Rosetta developers do follow this list. But we are only three people, one having arrived recently, and at times we simply can't keep up with the email! On the one hand we're working as a development team, but on the other hand, the Intrepid work has added hugely to our operational workload. Besides nursing overloaded servers and chasing up import errors, we've been rebuilding expertise and catching up on work that we lost with Carlos, and re-establishing the bridge between the translation-specific sections of the Ubuntu and Launchpad teams. Those last parts are key. It's been hard work, and there will be more of it, but I think now we're slowly moving towards dry land instead of just treading water. We're getting and implementing some concrete ideas that will reduce the workload. And we're communicating better about the state of the process, putting us in a better position to spot and address problems in time. I know that Canonical is looking for someone to fill this position, but until then, I believe we (both translators and developers) should try to at least better document the translation process of those packages that constitute exceptions (e.g. debian-installer, WUBI, language-packs, to name a few). That would be great! This is exactly the sort of initiative a coordinator would be taking. Some of the exceptional packages also require special treatment in the Launchpad code, and I would love to match those up with community documentation. By the way, anyone who may be able to fill this position, please check out the job opening: http://webapps.ubuntu.com/employment/canonical_UTC Another proposal would be to create an additional translation list with the purpose of keeping track of new template uploads, so that translators know there is something new to translate before it is too late, or whenever a string freeze is broken. I would initially restrict this to those packages where Ubuntu or its variants are upstream, otherwise this might quickly become unmanageable. I am again taking Debian (debian-i18n) and GNOME (gnome-i18n) as a reference, where this seems to work quite well. Again, I know there is a blueprint specifying RSS template updates in Launchpad, but we cannot wait indefinitely until it is implemented. Every single release we have exactly the same issues. This, too, is one of those things I've been hoping to see. Not necessarily just template changes, but coordination across translation teams in general. My impression so far has been that automated RSS feeds can do part of the work, but not all. I understand your position. The only short-term improvement I can imagine in this process at this point is better information flow (i.e. that translators know at least how it all works) and translating directly upstream. Locking the upstream translations would even be better, but that is again material for another discussion. Colin, this may have come up before but might it help to register the Ubuntu version of the installer as an independent project on Launchpad? That
Re: Current Intrepid translation issues page
Gabor Kelemen wrote: I understand that, but -the problem still exists -then it should be solved some other way: how about grabbing the translations exported for language packs, putting them back into the last sources and recompiling only with this change? That's still a pretty long feedback cycle! You're talking about days at minimum, probably much longer before a newly translated message can make it back in. Most of this involves how the packages are built (just outside my daily field of view, so I can't say much about it), but you mention server and developer time and obviously those are limited. So unless this turns out to have a really simple solution, we would have to opt not to do other things that many people will want instead. The fact that Soyuz, Translations, and Ubuntu are all involved could increase the engineering cost a lot. So given that, the cycle really should go through upstream. Even the ubuntu-specific gconf schema descriptions? :) Obviously not, and I hope at some point we can start looking at supporting more of those things directly in Launchpad Translations. But for something like a list of cities in libgweather, I imagine it's better for both upstream and Ubuntu if Ubuntu translations become upstream contributions than effectively having them live outside Launchpad! Yeah, personally, I hate them too. Perhaps we could declare intltool evil and start an anti-xml, anti-custom-formats campaign at conferences or something ;). Hmm... Have you devised your own XML translation format yet? Then what are you doing at a party for adults? Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Timeout errors on translation upload
Gabor Kelemen wrote: David Planella írta: Hi, I am trying to upload a couple of PO files without success. It seems that the problem with the timeouts has come back. I can see it too: (Error ID: OOPS-1026D4336) - published upload to app-install-data We're investigating an apparent deadlock issue. Of course it's also possible that this is a load spike from other causes. Does retrying work? Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: desktop-* (KDE4) and some other PO files not imported at all
Kenneth Nielsen wrote: Isn't manually uploading to compensate for lack of automatic integration of upstream translations, a bit like peeing in your pants to stay warm? As far as I know, as soon as you upload manually it counts as a LP translation, which means that all the usual fun and horror with override priorities start kecking in. Personally I would leave it, the only effect the users will see are bad translation for the first month or so, but I really don't think it is worth introducing permanent work for us to fix that. I can't say I've tried that method of staying warm, but manual uploads can make sense: the Ubuntu package builds pump hundreds of thousands of files into the translations import queue, and some proportion of them will fail. And it's not usually clear who should be notified about those failures. If somebody then steps up and re-uploads the files that failed to import, the system will notify them of any errors and they can be handled on a case-by-case basis. For instance, we just discovered that a bunch of KDE files used a bit of syntax that our parser couldn't handle: #~| to mark old msgids of messages that are both fuzzy and obsolete. So we stripped out the offending lines and re-uploaded just the affected files. There were only about 1400 of these, so the automated blind upload took care of most of the work and made it possible to do something about the missing ones. Something else I'd like to do about this (when there is time! :-/ ) is to make the failure messages accessible from the import queue UI. See the blueprint here: https://blueprints.launchpad.net/rosetta/+spec/import-queue-failed-error-display Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Current Intrepid translation issues page
Gabor Kelemen wrote: The gweather location's translations are taken from an xml file, which is filled with translations at compile time. Launchpad however doesn't seem to export and put translations back to the sources before compiling the package, so updated translations are not used at all if they should go into xml files. That sounds like a circular dependency: we get the translations from the built package in the first place. Building packages, importing translations, and exporting translations are all huge jobs that need to run independently. So we can't stop the build somewhere in the middle to import the translations, export them together with Launchpad changes, integrate them into the package, and continue the build. The cycle is just too long for that. So given that, the cycle really should go through upstream. The application could do more to facilitate that, but ultimately it's up to the translators. That affects lots of other packages, like xkeyboard-config[1], compiz-fusion-plugins, gcompris, xscreensaver - just to name some. And the .schemas files for gnome programs using gconf are xmls too. I don't suppose the fact that it's XML matters much: the underlying problem is a combination of custom formats and bidirectional feedback in the build procedure. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: new strings in ubuntu-docs
Matthew East wrote: Jeroen: there are still 4 pot files to be imported and over 1000 po files: what are the chances these will all be done by Sunday 19? Just checking: these were the ubuntu-docs ones, right? I had their priority bumped up, but I think they would have been imported by then in any case. A great majority of the files still on the Approved queue are OpenOffice ones. I moved those to the back of the queue (as before) because we've already run full OpenOffice imports, and these would probably give us relatively little compared to the other files we could be importing in the same time. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs updates for translation into Intrepid
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 ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Are the templates for synaptic, update-manager and update-notifier up to date?
Milo Casagrande wrote: Looking at the import queue of synaptic, there's only one pot file but it's in need review from June... So, I think this one _should_ be up to date. If it's in need review, that means it's not been approved for import. Which means it's a version of the template that hasn't been imported yet. Arne, any idea whether that template should be approved? For the other two packages, looking at the import queues, there's one pot in each of them that has been uploaded 14th October. Status is Approved, but I don't think imported yet... We're still importing uploads from October 6, so it'll be a few more days before we get to that one. You can see the full queue at https://translations.launchpad.net/+imports Once a file's been successfully imported, its state will change to Imported (bet you saw that one coming) and the queue entry is cleaned up soon thereafter. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: new strings in ubuntu-docs
Matthew East wrote: As for translations, in past releases we have traditionally tended to download translations at the LanguagePackTranslationDeadline (in this case 23 October) rather than the earlier deadline. In particular given the recent problems, I think we should do that again, I'll clear it with the release team. That will give translators at least an extra few days. Thanks. That also gives us a much better argument for rejigging the priorities again. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs updates for translation into Intrepid
Matthew East wrote: I would have thought that pot templates should be given priority over po templates in the queue. There is a problem with that: it means that people start translating without seeing what work is already done but waiting for import. So you could end up with the same translation effort going into much less useful things. I don't see that. As long as there are po files waiting for import, there will always be people starting translation without seeing what work is already done (unless they check the import queue carefully). However, with pot files, these contain *new* translations so none of the translators can see them until they are imported. That's why I think these should have priority. 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. Can you give me a very rough impression of what that ratio is likely to be for the pending ubuntu-docs? (There are other prioritization criteria of course. We generally don't do that because any algorithm is likely to have weaknesses, possibly even starvation risk or other pathological cases. But we can cheat a little by asking admins to modify certain upload dates.) Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs updates for translation into Intrepid
Matthew East wrote: The queue hasn't decreased at all since my last post, it's now at 1174 following a few manual uploads. That's because of their place in the overall queue. There are still a bit over 3,000 files in front of the first ubuntu-docs uploads, so it'll be at least another day before the importer gets to those. I've been asked to prioritize debian-installer as well, though I believe those will go through pretty quickly. What concerns me the most is that a large number of pot templates have not been imported, so even translators working through the interface and not relying on imports cannot work with the latest English documents. What that means I think is that translation of ubuntu-docs is pretty much a write off for this release. [...] I would have thought that pot templates should be given priority over po templates in the queue. There is a problem with that: it means that people start translating without seeing what work is already done but waiting for import. So you could end up with the same translation effort going into much less useful things. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs updates for translation into Intrepid
Matthew East wrote: Danilo, There are still 1171 items in the ubuntu-docs queue. Is there anything that can be done? It looks like they're simply waiting for the importer to get to them. The server that does that work is under heavy load and so far, we haven't had much luck in finding more CPUs for it. We are optimizing the scripts that keep the server so busy, so hopefully we can speed things up a bit over the coming days. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Call for intrepid translations
Timo Jyrinki wrote: Just a quick update: Progress, yes, but there are still (at this moment) over 40 thousand PO or POT files queued for import: https://translations.launchpad.net/ubuntu/intrepid/+imports?field.filter_status=APPROVEDfield.filter_extension=all That's down to about 36600 now, although of course a few hundred new ones have been uploaded as well. We're working on optimizing code to reduce load on the server. Server load is currently the biggest bottleneck. The progress is that they are Approved now, which is great, but the time is getting short regarding getting them all in on time, especially as new stuff is being uploaded all the time and the deadline of some of the translations is on 16th of October. OpenOffice.org imports are the heaviest. We can move those to the end end of the queue so more shorter jobs can get through. There is also currently 53 POT files still needing review still at https://translations.launchpad.net/ubuntu/intrepid/+imports?field.filter_status=NEEDS_REVIEWfield.filter_extension=pot (is there some problem with the app-install-data-ubuntu, it's still not Approved?) and 13 000 PO files needing review. Arne is working on figuring out which templates go where. If you see something that needs his attention, it may help to contact him and inform him of what should be done with that template: correct translation domain, included in language pack or not, any complications such as a template having moved from one template to another. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: No KDE upstream translations imported to Rosetta?
Timo Jyrinki wrote: As the KDE4 pot:s seem to be imported now (though po files not yet), there's only 132 Needs review pot:s queued. Of those, I'd like to point out this one: https://translations.launchpad.net/ubuntu/intrepid/+source/app-install-data-ubuntu/+imports ...just because being able to translate those entries in gnome-app-install would be a major l10n improvement in intrepid. We were still having some trouble with KDE auto-approvals, which I hope is now behind us. The actual imports were also slow because there were still some OpenOffice ones in front of it in the queue, and those things are huge. Hope that's behind us for now as well. Arne, could you look at that template Timo pointed out? Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Intrepid translations
Jochen Skulj wrote: Can you tell me if the translations of the ubuntu-doc package were taken over from hardy to intrepid? Our translators worked in the last weeks and even the last days on the hardy translation in the hope this translations would be taken over to intrepid. If there was no take-over or much earlier versions of the translations were taken over is there an easy way to restore the updated hardy translations in intrepid? Could I maybe just export the po files from hardy and import them to intrepid? IIRC ubuntu-doc is translated as a separate project, not as an Ubuntu package. Is that correct? If so, there was no copying but you can export the Hardy translations and upload them to the Intrepid release series. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Intrepid translations
David Planella wrote: when are the upstream (e.g. Gnome) translations going to be imported to Intrepid? Only after the 2.24.0 and 2.24.1 release dates? And how many such importations are there going to be? I mean, are the upstream translation data going to be imported on a periodic basis before the Intrepid release, or are there going to be just puntual importations? I think the Ubuntu people will be able to tell you more about that. Arne, Martin? Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Intrepid translations
Open now. Devastated to have kept you all waiting. We're working to make sure this doesn't happen again! Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: BSD licence
Milo Casagrande wrote: --- Mar 1/7/08, Matthew East [EMAIL PROTECTED] ha scritto: The problem with that is that because of the fact that translations from upstream are generally not imported immediately in Ubuntu, and the solution is often for the translation team to upload the upstream translation in Rosetta. At least I believe that is how the Italian team does things. Yes, we've always done that for speeding up the process. It's from before my time, but I believe that's why we talk about published uploads instead of upstream ones: it means they come from somewhere upstream from where they're being imported, but not necessarily from all the way upstream. So as long as an upload is marked as published, Launchpad knows it's not the original source and knows not to assume it's BSD-licensed. The change we're going through now should make it easier for us to explain this in the future, without too much legalese. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Request for info about the BSD licence change
nglnx wrote: -- Am I correct to assume that suggestions that come from GPL projects will be visibly flagged regarding potential licensing conflicts? Yes. -- Also, a related question: when you use a suggestion, does the string become BSD licensed or does it retain the original license? Assuming we're talking about a suggestion that was created in Launchpad itself: it will already be BSD-licensed while it sits in the database. That does not wait until you use it. Note that for small amounts of text, or things that can't reasonably be translated very differently, copyright doesn't restrict your usage anyway and you can just ignore all of this. In that case I don't see any difference between using a suggestion on the one hand, and writing your own copy on the other. To be honest, I think that's probably the most common situation. -- What happens with changed in Launchpad translations? Since our contributions are now BSD, if upstream GPL project has an error and you want to correct it in Ubuntu, are you able to do so or not? When you export those translations, you are generating a file that is essentially the GPL'ed translation but with some additions that are *also* covered by BSD. That's assuming that you're making sufficient changes for copyright to have anything at all to say about it, of course; otherwise, the whole thing is simply GPL. -- Is the following correct? Imports marked as published will retain original license. Only contributions made in Launchpad will be BSD. It will be up to the upstream to use it or not. Yes, that's correct. -- Since it is asked that contributors licence all *past* and future translations, what happens for past contributions. Do past suggestions accepted, imports made, corrections to upstream translations in Launchpad, etc., have to be reviewed to comply with the new requirements? That could become a problem to those with considerable contributions. The existing terms already said that the translations made in Launchpad can be relicensed to other projects, so as I see it, those terms allow this change. (On the other hand, the FAQ said that they were BSD in the first place, so if that's all you saw, there is no change at all). For suggestions from imports, we'll do our best to identify ones that came from published sources and warn about cases where there might be a problem. But of course whether there really is a problem ultimately won't depend on any single translation message; it's the complete work that matters. -- Regarding licensing conflicts, your FAQ states that checking compliance is the responsability of the contributor. Shouldn't this be included in the revised terms of use page, instead of just the FAQ page? That's a good idea. I'm not sure it's a term of use in its own right, but it would be clearer. Of course we'll also be mentioning it in the UI where it becomes relevant. -- IANAL and most of the contributors also are not. Has this licence change been reviewed by one (at Canonical, for instance)? Yes, it's been reviewed inside Canonical. -- Have any translation teams changed their workflow or membership requirements in any way to reflect the licencing change? Being member of a translation team, I would like to know how other teams are adapting to the change. Not that I know of. In practice, we believe very little will change. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: BSD licence
luca (ᴉ) innurindi wrote: Good, so the upstream translations remain with their own license, but what do you think to do in the cases where an user uploads them after the automatic import in Launchpad because they weren't complete at that time? Uploading them again, but as published. AFAICS that will fix it. [...] So, while we do understand there are some risks, we feel they are very low. Whty do you think so? IMHO I see nothing that prevents someone from profiting from this license. Everyone registered in Launchpad can export the pos and distribute them with hia own license. That's possible, but we also asked ourselves: what's to stop a proprietary project from basing their translations on (for example) GPL'ed ones they find on the Internet, and publishing the free parts separately from their proprietary binary-only application? Or to set up a pointless BSD-licensed project that happens to use the same translations as their proprietary application? It's more work, we do see that, but it can be done. A license by itself doesn't stop it. What limits the problem in practice IMHO is the difference between programs. There are many strings that come back again and again, but there are also many strings that don't. The more a string comes back, the more likely it is to be of use to another project (which may be proprietary) but also, the less weight it's likely to carry when you compare translations for copyright purposes. The most popular strings are all short, and many of them are dictated by style guides and such. Nobody can monopolize those(*), and anybody will be able to translate those the same way regardless of license. (*) With one possible exception: somebody seems to have translated Quit to Dutch as Native American. That--how do I say this--would not have occurred to me. :) I hope it's just a fuzzy match. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Copying translations between releases
Imre Kalomista wrote: It is not likely that I would want to have the same string translated differently in different releases, so I think that the obvious advantages of this process outweigh the risks. If I do want to have a different translation - can't think of any specific cases but it is possible -, I can keep an eye on the specific package/string and correct it if necessary (that would be possible, right?) Absolutely. If you review translations you might think hey, this translation may not be right for later Ubuntu releases, and undo the change there. As has been pointed out, where this happens, the English text is likely to have changed as well. In that case there is not going to be any problem at all. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translating from a language other than English
Efrain Valles wrote: I have a simple question. Can anyone translate to a specific language from another language other than English?. Not in Launchpad, no. That is not going to change. You'd have to translate to English first, and start using the English as the original strings. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Failed import
David Planella wrote: * http://launchpadlibrarian.net/10690374/ca.po (timer-applet) * http://launchpadlibrarian.net/10690285/ca.po (gnome-panel) * http://launchpadlibrarian.net/10690351/serpentine-ca.po (serpentine) * http://launchpadlibrarian.net/10690366/olive-gtk-ca.po (olive-gtk) A-ha! I think I have it. You're translating the translator-credits message in order to add Launchpad credits. But Launchpad produces those credits automatically, so that translation should be ignored. It seems there's a bug in how we deal with those, however, and the import fails when this happens: https://bugs.launchpad.net/rosetta/+bug/173144 The workaround is to remove translator-credits messages from non-upstream translations. Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Failed uploads because of translation credits bug
Hello all, We've just uncovered a bug in Launchpad Translations 1.1.11 that caused a few translation uploads for Ubuntu to fail *without notifying the uploader*. The problem is rare, but please read on to see whether you might be affected. The bug ticket describing the problem is here: https://bugs.launchpad.net/rosetta/+bug/173144 The problem occurs when importing a non-upstream translation that provides a translation for a translation credits message. Such messages should be ignored since Launchpad itself keeps track of who has contributed, and generates the list automatically. As far as I can see, the following Ubuntu translations have been affected (I've contacted non-Ubuntu uploaders separately): Language (code) Template Product --++-- Catalan (ca) gnome-panel-2.0 gnome-panel Croatian (hr) rhythmboxrhythmbox English (Canada) (en_CA)gourmet Gourmet English (Canada) (en_CA)internet ubuntu-docs English (Canada) (en_CA)internet xubuntu-docs English (Canada) (en_CA)serverguide ubuntu-docs English (Canada) (en_CA)switchingxubuntu-docs English (Canada) (en_CA)windows ubuntu-docs English (Canada) (en_CA)windows xubuntu-docs Hebrew (he) rhythmboxrhythmbox Indonesian (id) xubuntu-docs-index xubuntu-docs Italian (it) internet xubuntu-docs Italian (it) keeping-safe xubuntu-docs Polish (pl) nautilus nautilus Spanish (es) kiviokoffice Even if you're not on this list, and even if you got no error emails, it's good to check your import queues every now and then to check that there were no failures. Until we can get this bug fixed, the way to avoid this problem is to look for any of these message strings in translation files, and remove them or comment them out: translation-credits translator-credits translator_credits EMAIL OF TRANSLATORS\nYour emails NAME OF TRANSLATORS\nYour names The fix should be included in the 1.1.12 rollout. I'm not planning an emergency fix, since the problem is rare and the workaround is better practice anyway, but I will continue to keep track and to notify affected translators. For Ubuntu translations, those notifications will come through this list. Thank you, Jeroen Vermeulen Launchpad Translation team -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Failed import
David Planella wrote: is there any way to find out why an import failed? I uploaded a timer-applet translation at https://translations.launchpad.net/timer-applet/head/+pots/timer-applet/ca/+translate, and it got marked as Failed on my import queue. However, I didn't receive any e-mail telling me about the reason (or that it failed at all), and Launchpad does not seem to offer more information either. We've had some teething problems with the big schema refactoring we rolled out last week, e.g. bug 165168, 165218. Normally you should receive an email giving this information, but that may not happen if there is an internal error. In that case we should still see an error message appear on our end, however, and we hope we've just about fixed these urgent problems. Could you try again, and check that the import really goes to IMPORTED state? Thanks for a very thorough report, by the way! Jeroen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
