* '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/language-packs-for-universe * '''Created''': <> by CarlosPerelloMarin * '''Contributors''': CarlosPerelloMarin, MartinPitt * '''Packages affected''': == Summary == Universe lacks any kind of Rosetta integration feature so it's difficult to get translations update for it. We need to provide a solution like the one for main or an improved one. == Rationale == Although we don't support Universe, people are interested on applications from Universe and thus, there are people interested on translate them and also in see them fully translated. This would allow a full distribution translation. == Use cases == * Peter wants to translate VLC for dapper. He knows it's not supported by Canonical but he really likes that application so he translates it and with next language packs, he gets his translation deployed. * Jordi found a bug in the Catalan translation of Galeon, he fixes it and waits for next language pack update to see it fixed for all Catalan users of that application. Galeon is in universe. == Scope == This spec requieres updates in: * Rosetta. * Depending on the solution chosen, we would need to update apt-get, update-manager, langpackomatic, libc, etc... == Design == We need a system that allows us to distribute translations for any application in Universe. It should fit the following requirements: * You would install only translations that you are interested on. No extra languages that are not related to your preferred ones or translations for applications that you don't have installed. * You should be notified when a new translation is available so you can get updates, even after release time. * The updates must not overwrite any file stored in our system that is handled by dpkg that are not related with language packs. * The metadata information to handle translation updates should be as small as possible. * The system must not be .po/.mo specific, it should update other files like documentation, .desktop files, firefox/openoffice language packs, and any other translatable resource we could have in our system. * We should be able to expand its usage to support our installer. This will allow us to use this solution with our 'main' repository so even if we choose a different approach from what we have in main, we could migrate main for that new solution. * The solution should be able to use mirrors to distribute the files so we don't overload launchpad or a single server. * The translations should be installed and available just after the application is installed. The user should not be aware that the translations are not part of the binary application, they don't care about it, they just want their application full translated just after its installation. * When an application is removed, its translations should be removed too so we don't waste resources. We will use exactly the same solution we are using in main. All translations for a group of languages are stored inside a single .deb package with a -base package for the initial distribution release and a -updates package for the monthly updates after release. Also, all translations from the binary packages are stripped so we only ship translations as part of the language packs. == Design Rationale == While thinking on this, we found several solutions. All them with their pros and their contras and we are going to document them here to be sure that we have those present if the requirements change: 1. Use exactly the same solution we are using in main. All translations for a group of languages are stored inside a single .deb package with a -base package for the initial distribution release and a -updates package for the monthly updates after release. Also, all translations from the binary packages are stripped so we only ship translations as part of the language packs. Pros: * Simple to manage, we have already all the infrastructure there to create/maintain/deploy it. Contras: * The amount of packages in universe is higher than in main and thus the language packs would be bigger. * You would need to install a lot of translations even if you are interested in just one package from Universe. * We would need around 200 new packages (100 for base, 100 for the updates) 1. Same solution as before, but without using -base packages and without striping translations from binary packages. Pros over previous option: * The initial language pack will be much more small because will only contain changes done in Ubuntu/Rosetta and the others will be part of the binary packages, so the users will have installed only the translations that they need + all updates for universe translations. * We will need “only” around 100 new packages for the -updates packages. Contras over previous option: * If translators do a good job, the size of the language pack would be directly high and thus we don't get a big win. * We would have two different language pack behaviours, main must do the strip to save some disk space for the installation/Live CD. 1. We could create as many packages as languages supports a source package so we could have something like: {{{ foo_0.1-0ubuntu1_i386.deb language-pack-af-foo_6.06+20060603_all.deb language-pack-ca-foo_6.06+20060603_all.deb language-pack-es-foo_6.06+20060603_all.deb ... language-pack-pt-BR-foo_6.06+20060603_all.deb language-pack-zh-CN-foo_6.06+20060603_all.deb language-pack-zh-TW-foo_6.06+20060603_all.deb bar_1.3-1ubuntu13_i386.deb language-pack-af-bar_6.06+20060603_all.deb language-pack-ca-bar_6.06+20060603_all.deb language-pack-es-bar_6.06+20060603_all.deb ... language-pack-pt-BR-bar_6.06+20060603_all.deb language-pack-zh-CN-bar_6.06+20060603_all.deb language-pack-zh-TW-bar_6.06+20060603_all.deb }}} Pros: * You will install exactly the translations that you want and nothing more. Also, you would remove them when the application is not being used. This means less disk space wasted. * We could update language packs more often than currently (once per month) because users will get only exactly the translations that they are using. Contras: * The amount of packages would explode a lot. Say we have around 35 languages on average and after some checks, we know that only 10% of universe's source packages have translatable resources and we have near 12000 source packages in Universe, that would mean that we will need around 38500 new .deb packages to ship translations and that number will grow when people start doing more translations. * Due the amount of packages we are talking about, the metadata information would be really huge and most of the time will be duplicated. * apt-get's Packages.gz file will grow a lot. 1. Same solution as before, but expanding apt-get to accept Packages-LANG.gz so we add the language packs to their own Packages file. This will be backward compatible because Packages.gz will still be there, but without translations and the new apt-get would get advantage of the language packs if they are present. Pros: * Same as before. * Mirrors could mirror just the languages they are interested on. Contras: * Same as before except Packages.gz will stay with an acceptable size. 1. Same solution as before, but using different components instead of adding the Packages-LANG.gz files. The good thing over the previous solution is that you don't need to change apt-get. The bad thing is that you would need around {{{35 * len(main, universe, multiverse, restricted)}}} new components. 1. Finally, we could stop using .deb packages to handle translations and create our `apt-lite` system integrated with update-manager and apt-get that wouldn't have dependencies or versioning system other than a catalogue with a list of source packages and links to its translatable resources. The system will just use MD5 sums to know if you have latest version of a translation and will warn you about new translations available. You will get only translations for installed packages and the system would remove translations for uninstalled applications. Of course, those files will be installed inside a directory ({{{/usr/share/locale-langpack}}}) that will not be handled by dpkg so we don't overwrite anything from dpkg. Pros: * The metadata will be really low. * We could update all translations daily if we want, that will not produce an update of the other translatable resources because every file is independent of the others. Contras: * Due we don't handle versions, we are not able to restore a distro release to its concrete release status related to translations. Jeff Bailey pointed this problem as a possible problem for the support team. * We need to do a light implementation of apt-get. * The mirroring scripts for Ubuntu cannot be reused to mirror translations. === Final decision === After checking all those options, we decided to go with the solution #1. The reasons we decided to choose that one are: * No new infrastructure is needed. * After some checks with Universe, we discover that although we have double of packages with translatable resources in universe than in main (around 1100 vs 550), the amount of translations is lower in universe than in main so universe language packs would be smaller than the ones in main. This would change in the future, but in the mean time, we could go with this simple solution. * The fact that we use -base and -update packages allows us to use exactly what we have in main so we don't need to care about different handling of language packs for main or universe. === Data preservation and migration === Nothing is needed. == Outstanding issues == == BoF agenda and discussion == {{{ ago 18 13:03:38 hi guys ago 18 13:03:46 hi sabdfl ago 18 13:04:14 is anyone from the distro side going to join us? ago 18 13:04:26 pitti ago 18 13:04:40 --> pitti (n=pitti@ubuntu/member/pitti) ha entrado en #cm ago 18 13:04:42 hi ago 18 13:04:43 hi ago 18 13:04:50 sorry, I have to learn when 'cm' is an abbreviation and when not :) ago 18 13:04:52 hey pitti ago 18 13:04:56 hi sabdfl ago 18 13:05:01 pitti: I have always the same problem ;-) ago 18 13:05:05 ok, let's start ago 18 13:05:08 sure ago 18 13:05:11 thanks for looking at this in paris ago 18 13:05:19 so, I gave this some thought ago 18 13:05:20 i wasn't in the discussions but i have read the spec ago 18 13:05:30 in the end, I think only solutions 1 and 6 make sense ago 18 13:05:52 the others seem to be abusing the archive structure and apt in nasty ways ago 18 13:06:15 sabdfl: our point was not to go with current language packs because we are scared of the other solution, but that we didn't have enough time for Edgy to do all modifications ago 18 13:06:28 so we choose the only realistic solution for Edgy ago 18 13:06:29 carlos: then drop universe for edgy ago 18 13:06:38 sabdfl: I think it boils down to: (1) can be done with a snap of the finger and is known to work, but not really pretty ago 18 13:06:48 and documented the others for edgy + 1 or any other release when we get some extra time ago 18 13:06:54 (6) is a lot of work, but offers better features ago 18 13:07:21 like direct integration into apt/synaptic/etc., so that when you install a package, you'd automatically get translations, too, etc. ago 18 13:07:24 i would like 6, but understand that it cannot be done for edgy ago 18 13:07:34 pitti: I think so, yes ago 18 13:07:48 the "translation manager" would need to get notifications, so it would know how to go look for relevant translations, yes ago 18 13:08:02 sabdfl: I also think (6) should be discussed with the admins to judge the ramifications of mirroring, etc. ago 18 13:08:02 danilos: just in case you don't know the document we are talking about... https://wiki.ubuntu.com/LanguagePacksForUniverse ago 18 13:08:14 carlos: yeah, I know what you're talking about :) ago 18 13:08:43 how big is the pressure for SOMETHING in edgy for universe? ago 18 13:08:53 not too big ago 18 13:08:56 btw, carlos and I shortly discussed solution (2) yesterday ago 18 13:09:00 will people be happier if we deliver better translation of main, for example, instead? ago 18 13:09:07 and we are in time to remove it now (nothing has been imported yet) ago 18 13:09:13 sabdfl: right now folks are crying for edgy translations ago 18 13:09:19 of main ago 18 13:09:20 for dapper the process works reasonably well ago 18 13:09:55 sabdfl: translation is always measured in its completeness, and it depends on all software being translated ago 18 13:09:57 are there any other nice features planned for edgy, like package description translations, or a better way to translate the menu items? ago 18 13:10:04 sabdfl: I didn't hear particular requests for universe translations yet ago 18 13:10:08 We already promissed universe lang packs not sure if officially, but people know about it, but I don't think it would be too bad to defer that feature ago 18 13:10:11 sabdfl: especially with things such as "stock" gtk+ buttons, menus, which end up translated even in non-translated stuff ago 18 13:10:14 but that might also be due to the fact that you don't miss what isn't there :) ago 18 13:10:21 danilos: we have SUCH a lot of stuff in main that could be better translated, i think universe is not the highest priority ago 18 13:10:50 sabdfl: it's not about A LOT, it's about WHAT: if people use regularly some stuff from universe, they'd want to have it translated, IMHO ago 18 13:11:00 sabdfl: yes, I think the package descriptions will be part of Edgy ago 18 13:11:04 sabdfl: e. g. I think getting a better process for firefox and OpenOffice should be higher prioritized than getting an awesome universe translation structure ago 18 13:11:09 at least I saw movement in that spec ago 18 13:11:10 danilos: we won't strip the translations from the packages, so they will get pre-release translations ago 18 13:11:18 sabdfl: yeah, right ago 18 13:11:20 could we stuff rosetta translations INTO packages at build time? ago 18 13:11:21 pitti: we are doing that already for Edgy ago 18 13:11:40 btw, can we shortly discuss the 'not strip packages' case? ago 18 13:11:41 sabdfl: I don't think that's possible until bazaar integration is done ago 18 13:11:41 so, for example, if there is a security update then you get newer translations too as a bonus? ago 18 13:11:44 this would be solution (2) ago 18 13:12:06 I don't know that much about our packaging infrastructure to be able to answer any of this :) ago 18 13:12:09 sabdfl: this would work, it would just be a huge hit if we updated translations without other updates ago 18 13:12:13 carlos: why, surely it can be done as an explicit msgset merge command during the package build? ago 18 13:12:16 and universe gets *very* few updates post-release ago 18 13:12:47 users will rightfully yell at us if they have to re-download all their universe packages just to get some new strings ago 18 13:12:51 pitti: well, it would allow us to say "get in and translate universe before release and most of those translations will go into the release itself" ago 18 13:12:52 pitti: wouldn't that solution involve patching all the software in universe? ago 18 13:13:01 that seems much worse to me than downloading an 1 MB update langpack ago 18 13:13:04 i agree, pakcage update just for translations would be bong ago 18 13:13:37 sabdfl: we don't have a way to get .po files directly from rosetta so we would need to develop a new script for that with some kind of XMLRPC API because parsing emails doesn't sounds like a good solution... ago 18 13:13:39 sabdfl: right, pre-release that's certainly fine, but still requires package rebuilds, version bumps, and lots of bandwith waste ago 18 13:14:08 pitti: true - a huge rebuild at rc1 would cause potential issues ago 18 13:14:17 sabdfl: TBH I'd prefer update langpacks (solution 2) over rebuilding packages, at least with our current way of doing source packages ago 18 13:14:19 i.e. I don't understand how did anyone think solution 2 would work: more patching of glibc gettext() stuff? ago 18 13:14:22 and we would have no easy way to correct bad rosetta translations discovered after release ago 18 13:14:42 danilos: yes, that's what I wanted to discuss ago 18 13:14:49 I think we have to do a glibc change anyway ago 18 13:15:17 I think it's a bad idea to rebuild all 1100 universe packages just to strip all universe translations ago 18 13:15:24 (1100 universe packages that have translations, that is) ago 18 13:15:38 pitti: but this would be for using translations from two different domains, or simply including a complete PO/MO file if there was a change in Rosetta? ago 18 13:15:45 so with both solution (1) and (2) we need that glibc hack for a transition period ago 18 13:16:04 danilos: the latter ago 18 13:16:08 danilos: I'd go with updating a complete mo ago 18 13:16:09 I mean, after a while, it would be simply including all stuff in langpacks ago 18 13:16:15 danilos: right ago 18 13:16:16 danilos: otherwise the runtime impact is too high ago 18 13:16:22 pitti: agreed ago 18 13:16:26 danilos: with solution 1 that is ago 18 13:16:48 but we should first agree to a high-level goal ago 18 13:16:55 sure ago 18 13:17:00 is (2) ever going to be better than (6) if we can actually do (6)? ago 18 13:17:15 if not, then I would rather defer, and do (6) for edgy+1 ago 18 13:17:16 do we want universe translations, like *now*, or do we want to do them in a really sophisticated and cool way, but in maybe one year? ago 18 13:17:23 pitti: the latter ago 18 13:17:28 btw, do you have any estimate of the size of per-language langpacks for universe? I figure they'd be huge ago 18 13:17:33 then edgy should not have universe translations ago 18 13:17:36 updates ago 18 13:17:36 i. e. (1)/(2) now or (6) later ago 18 13:17:44 danilos: no, they aren't ago 18 13:17:46 danilos: less than main ago 18 13:17:50 danilos: in fact ATM they would be smaller than main ago 18 13:17:55 hum, nice :) ago 18 13:18:08 the most translation-laden stuff is desktop stuff, which is mostly in main ago 18 13:18:11 danilos: universe packages translations are really bad compared with main ones ago 18 13:18:11 I'd vote for better implementation, even if it delays it ago 18 13:18:13 danilos: the packages are less popular, therefor less translated (and often less likely to be translatable) ago 18 13:18:39 ok, this looks clear to me - don't try to do it badly for edgy, focus on better quality translations of main ago 18 13:18:53 that's why we stated that global universe langpacks would be a possible alternative ago 18 13:19:10 ok ago 18 13:19:25 if we do (6), then we probably lose some of the infrastructure features of apt ago 18 13:19:38 if we do (6) we should keep it super simple ago 18 13:19:41 like, straightforward mirroring, CD burning, debmirror, etc. ago 18 13:19:54 pitti: we added a solution for that, right? ago 18 13:19:55 jigdo? :) ago 18 13:20:01 the "packages" file should just be names and dates ago 18 13:20:02 but if we do a simple and efficient HTTP lookup/download and a nice integration into apt, this should cover the common case as well ago 18 13:20:10 prepare a .deb package that installs the initial .mo files ago 18 13:20:18 to include it in the installation CD ago 18 13:20:18 i would not integrate into apt, have a separate tool which handles it ago 18 13:20:25 carlos: +1 ago 18 13:20:45 sabdfl: apt integration> I meant 'apt-get install foo' would also take care of downloading the corresponding translations for your selected languages ago 18 13:20:46 what initial .mo files? are there any from universe on installation CD? ago 18 13:20:48 I think that would be cool ago 18 13:21:01 pitti: +1 ago 18 13:21:03 sabdfl: likewise for g-a-i, synaptic, etc. of course ago 18 13:21:14 danilos: universe packages aren't shipped on CDs ago 18 13:21:35 pitti: so why the need for "initial .mo files" (I may be misunderstanding this altogether) ago 18 13:21:38 ? ago 18 13:21:42 danilos: we start with universe and if it works, we will move it to main ago 18 13:21:53 so we need a solution for main too ago 18 13:21:56 carlos: ah, ok ago 18 13:22:02 even if we are not going to use it with first release ago 18 13:22:22 carlos: that's what I mean with 'losing infrastructure features' ago 18 13:22:26 sabdfl: the idea is to use an apt-get hook to do that installation that pitti said ago 18 13:22:34 i. e. it's nontrivial to ship langpacks on CDs that way ago 18 13:22:38 of course it's possible ago 18 13:22:44 yeah ago 18 13:22:59 pitti: but that's the same problem as no using apt-get and dpkg standard infrastructure ago 18 13:23:05 carlos: isn't it simpler to provide a file:/// handler at the same time as http:///, so you can install them in the same way from CD? ago 18 13:23:18 if we're to go with patching apt-get, that is ago 18 13:23:38 apt-get should just call a hook, which then calls 'update-translations pkg-foo' or so ago 18 13:23:39 danilos: not sure, we should expand the spec after edgy release (or once we get all our tasks done) ago 18 13:23:51 apt-get itself should know as little about this langpack thingy as possible IMHO ago 18 13:24:01 pitti++ ago 18 13:24:29 we should try to get this solution working without patching a bunch of packages ago 18 13:24:32 so, solution (6) needs some long and intense discussion, we should do this in person on the next meeting with admins involved, too ago 18 13:24:58 pitti: agreed ago 18 13:25:11 also, I think Jeff should be present too ago 18 13:25:14 carlos: yes, the initial infrastructure would boil down to 'download de/es translations from this server and put them into this path', and the matchign glibc patch ago 18 13:25:26 pitti: yeah, and I'd still want to push some more features into language packs when that discussion happens :) ago 18 13:25:28 and then we need the proper integration into the package managers and language selector ago 18 13:25:45 we could over-engineer this very easily :-) ago 18 13:25:53 here's what I would care about ago 18 13:26:10 (1) the index file has a date, so you always know if one is newer than another ago 18 13:26:25 (or just a counter) ago 18 13:26:45 (2) the index file is as small as possible, so we don't get a Packages.gz style multi-mb download just to find out if you need to fetch new translations ago 18 13:27:28 (3) each updated PO/MO file is listed with just distrorelease, name, language and date, so again you always know if you have the newest ago 18 13:27:35 it should become something like 2000 packages * 100 languages * 50 byte per entry = 10 MB ago 18 13:27:49 hmm... index per language, then ago 18 13:27:53 right ago 18 13:28:10 I doubt there'd be 100 translations per package in universe ago 18 13:28:12 this will spread the load on the mirrors and bw requirement ago 18 13:28:17 only best translated packages have that many ago 18 13:28:20 no, this was just a maximum estimation ago 18 13:28:22 so system needs to track "which mo files do I need, and which do I have, and what dates are on them" ago 18 13:28:26 danilos: but we would have them for main ago 18 13:28:45 danilos: it should scale by the number of languages installed, not available ago 18 13:28:53 max. 100 kB index per language sounds reasonable ago 18 13:29:00 so if people install more languages, they need more index files, not the other way round ago 18 13:29:07 most users will only care about one or two languages anyway ago 18 13:29:12 exactly ago 18 13:29:17 sabdfl: that's a better reason ago 18 13:29:31 and 100 index files on the mirrors sounds reasonable, too ago 18 13:29:31 another nice thing is that we could make it easy to turn on automatic language updates ago 18 13:29:40 because it's not like packages where you definitely want user approval ago 18 13:29:44 update-notifier! :) ago 18 13:29:45 newer translations are better ago 18 13:29:51 it should just DOIT ago 18 13:29:57 unless the sysadmin has turned that off ago 18 13:30:03 yeah ago 18 13:30:10 sounds good ago 18 13:30:14 sabdfl: well, a 'do this automatically from now on' checkbox ago 18 13:30:17 i would like us to develop this, use it for universe, and then use it for main too if it is smooth ago 18 13:30:19 for the poor modem users ago 18 13:30:28 sure ago 18 13:30:45 pitti: just like update-manager handles automatic .deb installation ago 18 13:30:51 we can also then to langpack updates on a per-package, per-language basis ago 18 13:31:00 for this solution we would gradually strip universe packages AFAICS ago 18 13:31:04 sabdfl: well, that's what we're getting with this :) ago 18 13:31:19 pitti: with the next update, I'd say ago 18 13:31:20 per-package> yes, that's the whole point of (6) ago 18 13:31:28 so translation teams can sign off on an updated package-language, then press a button and queue it for publishing ago 18 13:31:50 so at first we wouldn't do any apt-get magic, but just do a little u-n integration and some backend which downloads and installs tarballs with mo files ago 18 13:31:55 pitti: i meant the timing of the updates, not the downloading of them ago 18 13:32:01 at the moment, we do them all once a month ago 18 13:32:15 but it would be better if a translation team completes a package for them to say "publish now, please" ago 18 13:32:16 sabdfl: I think with that granularity they could even be updated daily ago 18 13:32:21 sabdfl: well, we can update just the ones updated that week... ago 18 13:32:27 sabdfl: even daily ;-) ago 18 13:32:42 sabdfl: we only update the ones that got new translations ago 18 13:32:44 yes, there should be a sweeper process which pushes newer translations out automatically after a while ago 18 13:32:46 well, the period doesn't matter so much, it can be adapted to the mirror load ago 18 13:32:56 but i think the translation teams will like being able to work, test work, test, "release" ago 18 13:33:23 pitti: will you talk to archive managers about putting these in the dists tree? ago 18 13:33:27 aha, option "pull directly from rosetta"? if we didn't have async exports, it would be possible today :) ago 18 13:33:41 do we want mirrors to be able to mirror just certain languages? ago 18 13:33:49 sabdfl: I think so ago 18 13:33:52 sabdfl: I don't think they will like it there; should probably become translations.launchpad.net or translations.ubuntu.com or so ago 18 13:34:02 sabdfl: if we have indexes per language, they'd already be able to ago 18 13:34:06 danilos: no, not from rosetta; the DDoS will kill it ago 18 13:34:06 danilos: we will push daily or on-demand to a staging server, and translators can fetch their updates from there ago 18 13:34:24 danilos: not just the indexes, but the actual mo files ago 18 13:34:33 hmm.. that's probably so little data it does not matter hugely ago 18 13:34:49 pitti: I am thinking only of the "work, test, work, test" part of sabdfl's idea: pull directly from rosetta for testing by translators ago 18 13:34:56 pitti: it could be even smaller than 100kb ago 18 13:34:59 danilos: right, that would work ago 18 13:35:15 danilos: but we shouldn't have a single server for the default updating mechanism ago 18 13:35:32 pitti: right, anyway, more discussions with infrastructure pending ago 18 13:35:51 if the index is just domain (mo template filename) and date (or counter) ago 18 13:35:52 that being said, yes, I can talk to the soyuz and admin guys about a proper place to stick them to ago 18 13:36:02 ok, thanks ago 18 13:36:12 sabdfl: the index should have also a link with the sourcepackagename ago 18 13:36:15 the archive itself, a separate hierarchy on archive mirror, network, or a parallel network ago 18 13:36:36 sabdfl: so we know the .mo files to install when we get a new package installed ago 18 13:36:41 pitti: i would like the default to be that current mirrors just acquire this data ago 18 13:36:52 because we are going to be taking it out of packages, which they would otherwise mirror anyway ago 18 13:37:13 carlos: the package can register those on installation ago 18 13:37:28 sabdfl: true; it should work with rsync, won't work with debmirror (I don't know which is used where) ago 18 13:37:31 so install the package, it tells the translation manager "i would use translation domains X, Y and Z" ago 18 13:37:38 we don't have that information on build time, we can guess it ago 18 13:37:44 sabdfl: but Rosetta knows it for sure ago 18 13:37:47 can't we have a simple "install-translations-for-current-languages MOFILE" which would be run in post-install? ago 18 13:38:01 right - and we can also fix packages like that by hand, it just has to be done once ago 18 13:38:06 sabdfl: hm, the index file should just be per-package, not per-domain ago 18 13:38:06 sabdfl: and we can expand this to support documentation translations without needed to rebuild the packages ago 18 13:38:30 pitti: i don't think it should be per-package, because translation domains are required unique in any event ago 18 13:38:41 sabdfl: that's not always true... ago 18 13:38:43 and a single package might have several domains ago 18 13:38:44 danilos: please do not mention 'simple' and 'modify all package's postinst files' in one sentence :) ago 18 13:38:56 sabdfl: it should, but some upstreams doesn't follow that rule ago 18 13:39:00 pitti: heh, ok :) ago 18 13:39:05 it should not be in the postinst anyhow ago 18 13:39:10 it should be async on package install ago 18 13:39:14 no, it shouldn't touch source packages at all ago 18 13:39:16 install the package, then later update translations ago 18 13:39:32 sabdfl: I agree ago 18 13:39:38 pitti: or touch them in an automated way that the builder can do for all packages, like stripping ago 18 13:39:38 update-notifier updates daily anyway ago 18 13:39:40 that should be enough ago 18 13:39:44 sabdfl: doesn't that disconnect "list of domains" and "sourcepackagename"? ago 18 13:39:53 and synaptic/g-a-i can also trigger it manually ago 18 13:40:09 btw, domain/package name doesn't matter so much ago 18 13:40:16 rosetta can export a mapping between them easily ago 18 13:40:19 danilos: the sourcepackage name is irrelevant. the binary package is the "user" of the translation data ago 18 13:40:31 I should probably not comment on packaging issues which I am not very familiar with :) ago 18 13:40:34 the binary package should just know which .mo files it *would* use ago 18 13:40:39 sabdfl: yeah, that's what I meant ago 18 13:40:54 and the translation manager can then go "ok, i'll see if I can find those for the languages we need on this system" ago 18 13:41:07 but that shoudl happen separately from package install ago 18 13:41:12 sabdfl: the 'would' is tricky :) ago 18 13:41:17 but why not per source packae ago 18 13:41:24 that wouldn't be much worse IMHO, but much easier ago 18 13:41:33 sabdfl: I still think that's rosetta's job ago 18 13:41:33 sabdfl: yeah, I just don't know enough of how one would find that out: "get-mo-files-for-package PACKAGE" ago 18 13:41:46 know enough about packaging, that is ago 18 13:41:47 often a source package shares a translation domain with several binaries anyway ago 18 13:41:47 pitti: it's no problem for the builder to say "ok, you didn't say anything about mo files, and I see your source package has these domains, you are going to say you need all of them" ago 18 13:42:04 so by default, we jam all binaries to say they need all the mo files from their source package ago 18 13:42:22 sabdfl: right, we can create such a mapping in pkgstriptranslations ago 18 13:42:30 but the developers could tweak that if its appropriate, in the small number of cases where one binary uses one mo file, and another uses a different one, all fomr the same source package ago 18 13:42:31 it knows the domain<->binary mapping ago 18 13:42:33 for perfectionists, let them run strace on programs and let us know of any differences :) ago 18 13:42:33 but we already have it in Rosetta.... ago 18 13:42:48 carlos: at the source package level, yes, not the binary package level ago 18 13:43:05 if we need a binary->domain mapping, let's create it in pkgstriptranslations ago 18 13:43:06 so, by default, the best we can do is assume that any binary produced by a source package, needs all the mo files produced from the same source package ago 18 13:43:35 then maintainers who care can tweak the packages so that binaries know *exactly* which subset of mo files they actually need ago 18 13:43:41 sabdfl: there are some situations ago 18 13:43:43 sabdfl: right ago 18 13:43:45 and then the client tool would download that mapping (tiny), then check out which domains it wants, and downloads the domain data ago 18 13:43:50 when a package doesn't have any .po file ago 18 13:43:58 but Rosetta have them ago 18 13:44:03 carlos: true ago 18 13:44:03 what would happen in that situation? ago 18 13:44:11 good point ago 18 13:44:14 the package will think there aren't translations ago 18 13:44:28 rosetta will need to tell the build system this information ago 18 13:44:28 but Rosetta knows that there are such translations ago 18 13:44:32 oh, and binaries might do bindtextdomain() which is shipped by other debs ago 18 13:44:43 pitti: yeah, iso_codes :) ago 18 13:44:45 well, let's do it by source package then ago 18 13:44:47 pitti: among the others ago 18 13:45:01 we can always switch the implementation transparently to per-binary on the clients ago 18 13:45:08 or php applications using .po files directly instead of .mo files... ago 18 13:45:22 it should definitely be possible for a binary to say "i would use mo file X" ago 18 13:45:43 and it should also require no work for maintainers, for it to "just work" by default, even if that results in slightly more mo files installed than needed ago 18 13:45:45 sabdfl: yeah, that was my idea of postinst, but there's probably a better way to do it :) ago 18 13:45:53 and then we can tweak the packaging to get the dependencies just right ago 18 13:45:57 sabdfl: at runtime, this is easy, but we need to figure it out statically ago 18 13:46:16 pitti: how do you mean, statically? ago 18 13:46:29 sabdfl: i. e. determine the domains an executable wants without executing it ago 18 13:46:35 on the buildds, for example ago 18 13:46:41 pitti: how hard would that be? if sourcepackage -> binarypackage1, binarypackage2, then domains for both binarypackages are same as source's ones ago 18 13:47:02 danilos: well, that's exaclty source package granularity, or am I missing something? ago 18 13:47:15 pitti: this is the first approximation, that's what sabdfl is proposing afaigi ago 18 13:47:30 and simply allow binary packages to be more specific ago 18 13:47:33 danilos: mark wants to install only a .mo file if the binary package uses it, so if binarypackage2 doesn't use any, we don't install any .mo file ago 18 13:47:43 i.e. you generate a static list like this, you can later modify it by hand ago 18 13:47:49 pitti: well, the binary package would either: ago 18 13:47:49 (a) have the mo files included, in which case we can strip them, and tell it to register its "dependency" ago 18 13:47:49 (b) depend on another binary package, which provides them, which would have the same thing happen to it ago 18 13:48:00 in most cases, you'd need no changes for most binary packages ago 18 13:48:17 sabdfl: unless we only have translations in Rosetta ago 18 13:48:21 sabdfl: i. e. for new languages ago 18 13:48:46 pitti: if there are ANY translations, we register the domain name ago 18 13:48:47 pitti: wouldn't you generate indexes and langpacks based on rosetta data anyway? ago 18 13:48:52 well ago 18 13:48:54 and KDE packages ago 18 13:48:55 sabdfl: yes, I agree it's a corner case ago 18 13:49:02 then if we add translations for new languages, the system translation manager would see them and fetch them ago 18 13:49:07 the binaries doesn't include any .po/.mo files ago 18 13:49:13 they have their own language pack ago 18 13:49:15 carlos: right, KDE is spethial, too ago 18 13:49:19 should we spec this in november? ago 18 13:49:25 we know we won't get to it for edgy ago 18 13:49:32 sabdfl: november> yes, would be nice ago 18 13:49:37 and we have 1.0 goals for rosetta ago 18 13:49:44 ok, then i'm very happy we had this conversation ago 18 13:49:48 sabdfl: yeah, I prefer to defer this until next meeting and talk a bit more face to face ago 18 13:50:01 if we all agree to do it right instead of do it now, then we should put more brain into this ago 18 13:50:03 carlos, will you summarise for the lists, and update the spec to say we will talk about it at the whole company meet in november? ago 18 13:50:08 I'm going to add this log to current spec ago 18 13:50:12 pitti: agreed ago 18 13:50:15 so we don't miss any of the points we did ago 18 13:50:15 carlos: great, thanks ago 18 13:50:22 thanks guys! ago 18 13:50:27 thank you, too ago 18 13:50:33 I'll let this mature a bit in my head ago 18 13:50:36 yeah :) ago 18 13:50:38 same here ago 18 13:50:46 pitti: could you talk with mdz about this? ago 18 13:50:48 it usually needs a few iterations :) ago 18 13:50:53 yeah ago 18 13:50:58 carlos: about the plan in general? sure ago 18 13:51:07 and the defer of the spec ago 18 13:51:21 we also have our admins at the allhands meeting, we'll need them, too ago 18 13:51:28 I will add again the restriction to import universe packages into Rosetta ago 18 13:52:02 and request Stuart to remove the entries we already have pending to be imported ago 18 13:52:19 carlos: what's wrong with importing universe translations at this point? ago 18 13:52:35 pitti: that people will translate something that never will be used ago 18 13:52:48 not exactly never, but not before edgy+1 ago 18 13:52:55 that's why we didn't import it for Dapper ago 18 13:52:58 well, not displaying it is a different point ago 18 13:52:59 and some translations may "rot" until that happens ago 18 13:53:03 danilos: but we prefer people translating main ago 18 13:53:08 carlos: right ago 18 13:53:19 carlos: OTOH I assume you can import the existing universe later without new uploads ago 18 13:53:23 carlos: and that would likely move serbian off the first position :) ago 18 13:53:36 pitti: it would be a bunch of work in our side that I would prefer to save if we are not going to use them right now ago 18 13:53:48 pitti: no, we cannot ago 18 13:53:55 pitti: do you want it backported to dapper?? ago 18 13:54:11 danilos: ;-) ago 18 13:54:17 pitti: or edgy? ago 18 13:54:34 dapper likely, if it's really to be lts ago 18 13:54:53 I think it changes a lot of things, we cannot add that to an stable release... ago 18 13:55:13 carlos: no, probably no backports ago 18 13:55:13 hum, possibly ago 18 13:55:20 pitti: then? ago 18 13:55:20 carlos: too intrusive changes on clients ago 18 13:55:34 why would you want to import universe later? ago 18 13:55:38 new glibc, new backend, new update-notifier, etc. ago 18 13:55:58 pitti: right, so lets forget about backporting ago 18 13:56:02 carlos: hm, true, just ignore me on this point ago 18 13:56:05 ;-) ago 18 13:56:52 ok, then do we agree on adding again the restriction for universe imports for Edgy and remove anything already in the queue for Universe? ago 18 13:57:09 carlos: yeah, I guess so ago 18 13:57:22 how do I find out what packages I have installed from universe? :) ago 18 13:57:23 I will remove it again when Edgy is released so we can import Edgy+1's universe ago 18 13:58:06 in fact... I think I'm just going to block dapper and edgy's universe ago 18 13:58:19 so nothing needs to change when we open edgy+1 ago 18 13:59:09 ok, thanks for all ago 18 13:59:15 * carlos updates the spec and prepares the email ago 18 13:59:43 thanks, guys }}} ---- CategorySpec