Failed import
Hi, 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. I do not know if this can be related to the fact that the statistics for this translation are wrong. I know about the bugs [1] [2] [3] related to this, but this time I'm referring to the number of untranslated strings (Catalan translation), which is also wrong (it shows 24 untranslated strings when in fact all of them are translated). [1] https://bugs.launchpad.net/rosetta/+bug/126963 [2] https://bugs.launchpad.net/rosetta/+bug/143964 [3] https://bugs.launchpad.net/rosetta/+bug/78917 Regards, David. -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Glade-3 in packs?
Hi Djihed, Today at 10:03, Djihed Afifi wrote: >> It's not our decision: it's a technically hard problem. The only >> assumption we make is that packages will contain proper POT and PO >> files. If that doesn't happen, it's easier to fix it in a package, >> than to try to construct a reasonable POT from all the PO files >> (i.e. you may end up with too many messages for translation which are >> obsolete, thus making translators do unneeded work, you may have >> conflicting messages in different PO files, etc). > > What's technically hard about compiling existing .po files from > upstream? > You don't need the original .pot files for that. That's something Ubuntu packagers have to deal with, if they want that. I can imagine why they may not want to do it, though (i.e. special casing for a handful of packages: it's ugly, not hard; it's easier to fix those few packages which have the problem by hand; etc). FWIW, that's what is currently being done for 'universe' packages. You may talk to Martin Pitt (CCed) about what he thinks of it (i.e. maybe not run 'strip-translations' when no .pot file can be found in the tarball). However, that will make it harder for us to track down problems like this (though, this is easily solveable: just report a bug for the package once this is done), and I still think it's more valuable to provide updated language packs. What I was talking about a technically hard problem is constructing a POT file when one doesn't exist. As far as LP is concerned, that's exactly the case, and we require POT file to ensure at least some level of correctness. We have an idea how to solve that, which would be equivalent to just "compiling existing .po files", but we don't like it for the reasons I mentioned. >> No, but I probably miss your point. What they, however, do lose is >> the ability to get updates with future language pack updates (the plan >> for Gutsy is to issue them monthly). > > I meant - Since Launchpad and the language packs can't get the glade-3 > catalog* - or any other package which can't build them, just roll the > translations with the package itself. Yeah, that's doable, but would have to be done on the Ubuntu side of things. I don't know much about it, but I've CCed Martin. >> Ubuntu is so far the best >> distribution when it comes to propagating translator work to their >> users (imo, though there's a lot to improve still), and that's solely >> due to Launchpad/Ubuntu > > No, it isn't. It's not better than a distribution that just rolls > everything with their original packages, and does no language packs. Have you never been late to provide updated GNOME translations by a few days (i.e. a maintainer rolls out a tarball 3 days before the deadline, and you do the update after that)? I am pretty sure you were, and if you want your translations in your distribution, you need to wait for the next major GNOME update in it. With Ubuntu, you just go to Launchpad, upload your translations, and wait for the language pack. > Sure that option may have drawbacks like bandwidth, but omitting whole > existing translations is not one of them. > > > >> >> > Not the right decision I believe. >> >> It's technically very hard to do anything else properly. > > Again, what's technically hard about rolling translations with their > original package? We can solve this either on the LP level, or on the Ubuntu level. I was talking from LP point-of-view. From Ubuntu POV, it's not up to me to say how difficult it would be, since I am not going to be the one doing the work :) >> Anyway, this is not because of Launchpad, this is because we're >> providing language packs for Ubuntu, and want to make sure that some >> data is at least correct. Launchpad itself works for much more than >> just intltool-enabled modules, so it can't regenerate POT files in the >> way damned-lies (on l10n.gnome.org) does. > > Either way, it is because of the bureuacracy in the middle. Bureaucracy > can't handle them? just roll it the old fashioned way! > > (I'm repeating myself here) This may require more effort than just fixing a package, though. >> And, fwiw, this might as well be broken behaviour in upstream Glade3: >> i.e. standard intltool build rules always create a POT file and put it >> in a tarball. There's a lot of sense in that, and not least of them: >> how would you start translating a package if it comes with no POT? > > If I am an end-user, I don't want to translate a package, my priority is > to get it. If I decide to translate a package, well in the case of > Glade-3, I do as I did and go spend hours on the upstream package to > translate it. And we want to make Launchpad a way to find faster how to contribute to translations anywhere. Glade-3 is a special case for you, since you are Arabic GNOME translation team leader, and Glade-3 is translated in GNOME Subversion. But there are other use-cases as well (like, you are Arabic translator and run into software which you don't
Re: Glade-3 in packs?
Hi Danilo, Thanks for the explanations. But I think you lost me there in semantics. > > It's not our decision: it's a technically hard problem. The only > assumption we make is that packages will contain proper POT and PO > files. If that doesn't happen, it's easier to fix it in a package, > than to try to construct a reasonable POT from all the PO files > (i.e. you may end up with too many messages for translation which are > obsolete, thus making translators do unneeded work, you may have > conflicting messages in different PO files, etc). What's technically hard about compiling existing .po files from upstream? You don't need the original .pot files for that. > > No, but I probably miss your point. What they, however, do lose is > the ability to get updates with future language pack updates (the plan > for Gutsy is to issue them monthly). I meant - Since Launchpad and the language packs can't get the glade-3 catalog* - or any other package which can't build them, just roll the translations with the package itself. Scheduling them for language packs and then not providing them at all is a mistake. If at a later stage this is remedied, both a language pack and a glade-3 pack should be reprovided to avoid conflicts. * (now it is thankfully fixed) > Ubuntu is so far the best > distribution when it comes to propagating translator work to their > users (imo, though there's a lot to improve still), and that's solely > due to Launchpad/Ubuntu No, it isn't. It's not better than a distribution that just rolls everything with their original packages, and does no language packs. Sure that option may have drawbacks like bandwidth, but omitting whole existing translations is not one of them. > > > Not the right decision I believe. > > It's technically very hard to do anything else properly. Again, what's technically hard about rolling translations with their original package? > > Anyway, this is not because of Launchpad, this is because we're > providing language packs for Ubuntu, and want to make sure that some > data is at least correct. Launchpad itself works for much more than > just intltool-enabled modules, so it can't regenerate POT files in the > way damned-lies (on l10n.gnome.org) does. Either way, it is because of the bureuacracy in the middle. Bureaucracy can't handle them? just roll it the old fashioned way! (I'm repeating myself here) > > And, fwiw, this might as well be broken behaviour in upstream Glade3: > i.e. standard intltool build rules always create a POT file and put it > in a tarball. There's a lot of sense in that, and not least of them: > how would you start translating a package if it comes with no POT? If I am an end-user, I don't want to translate a package, my priority is to get it. If I decide to translate a package, well in the case of Glade-3, I do as I did and go spend hours on the upstream package to translate it. And then sit and wait for ubuntu to deliver them and wonder where my work has gone. Djihed -- Have a project you would like to be translated to Arabic? Let us know: http://wiki.arabeyes.org/Translation_requests Blog: http://djihed.com -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Glade-3 in packs?
Hi Djihed, Yesterday at 15:05, Djihed Afifi wrote: > I don't think your decision is sound though. So because it doesn't do > what launchpad expects it to do, you just drop its translations from > packages? It's not our decision: it's a technically hard problem. The only assumption we make is that packages will contain proper POT and PO files. If that doesn't happen, it's easier to fix it in a package, than to try to construct a reasonable POT from all the PO files (i.e. you may end up with too many messages for translation which are obsolete, thus making translators do unneeded work, you may have conflicting messages in different PO files, etc). We did discuss something like this: https://blueprints.launchpad.net/rosetta/+spec/autogenerate-missing-templates-in-packages Anyway, we have not yet dedicated to working on this, simply because of the above reasons. > What happens to an ordinary person building the package from tarball > sources, do they lose translations? No, but I probably miss your point. What they, however, do lose is the ability to get updates with future language pack updates (the plan for Gutsy is to issue them monthly). Ubuntu is so far the best distribution when it comes to propagating translator work to their users (imo, though there's a lot to improve still), and that's solely due to Launchpad/Ubuntu > Not the right decision I believe. It's technically very hard to do anything else properly. > At this time, I'm wondering how many other packages are dropping > translations because of Launchpad. Not too many, we've had a few (I remember one other from the last 5-6 months) bug reports like this. Anyway, this is not because of Launchpad, this is because we're providing language packs for Ubuntu, and want to make sure that some data is at least correct. Launchpad itself works for much more than just intltool-enabled modules, so it can't regenerate POT files in the way damned-lies (on l10n.gnome.org) does. And, fwiw, this might as well be broken behaviour in upstream Glade3: i.e. standard intltool build rules always create a POT file and put it in a tarball. There's a lot of sense in that, and not least of them: how would you start translating a package if it comes with no POT? Anyway, a short-term solution is to fix the package. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
