[04:44] <lamont> carlos?  or who was it
[04:48] <carlos> lamont, hi
[04:49] <lamont> carlos: I'm looking at what the cleanest way to kludge around the translation tarball issue is...
[04:50] <lamont> given that it's perfectly possible for you to wind up fetching the bad tarball before the good tarball exists, does it make sense for me to just provide you with all the tarballs, and let you sort it out?
[04:50] <carlos> which tarball issue?
[04:50] <carlos> I was not aware we had an issue...
[04:51] <carlos> or at least I don't remember it...
[04:51] <lamont> 64-bit build apparently don't believe in gettext for whatever reason, and therefore you get tarballs with no .mo files or some such
[04:52] <carlos> lamont, oh, well, that's not a big issue
[04:53] <carlos> lamont, we are not importing breezy yet
[04:53] <carlos> so either remove broken tarballs or as you said, rosetta will take care of it
[04:53] <carlos> when the new version fixed is imported
[04:56] <lamont> I think the concern was that some breezy packages might not be rebuilt before release, after a gettext-check fix is in place
[05:03] <carlos> lamont, if the problem is just with .mo files
[05:03] <carlos> don't worry
[05:04] <carlos> we can fix it by hand
[05:04] <carlos> unless it's really easy to fix it in your side
[05:11] <lamont> pitti finds the current 'fix by hand' solution to be labor intensive
[05:11] <carlos> lamont, not really as we reuse the information we already have in for hoary
[05:12] <carlos>  s/in for/for/
[05:12] <carlos> so we need to fix it anyway 
[05:12] <lamont> ah, mo info?  these may be bad hoary files that he's working on...
[05:12] <carlos> lamont, yeah, he did a bunch of fixes with missing .pot files
[05:12] <lamont> that's probably what brought the subject up and led to him poking me...
[05:12] <carlos> I have it in my queue
[05:12] <carlos> hmm
[05:13] <carlos> then it's different
[05:13] <lamont> he's trying to get things long term to have the right stuff
[05:13] <carlos> lamont, yeah, please, fix it but don't worry too much about old versions, we are all busy but I can fix it with a couple of mouse clicks
[05:14] <carlos> and store it in our database
[05:14] <lamont> the set of issues hereare: 1) the whole delivery mechanism is ugly/hackish and needs to be replaced for bob to build it cleanly. 2) all the buildd's deliver the same file, and newer (sometimes incorrect) files overwrite older ones
[05:15] <lamont> 3) any change to the current hackish delivery mechanism requires changes to said hackish delivery mechanism, in multiple places.
[05:15] <lamont> Kinnison: you got that you require a clean solution to this for launchpad, right?
[05:16] <lamont> Kinnison: please don't promote crack....
[05:16] <Kinnison> lamont: langpacks?
[05:16] <lamont> Kinnison: got it in one.
[05:16] <Kinnison> lamont: the buildd master will invoke the relevant rosetta functions directly on extracting the langpack from the slave
[05:17] <carlos> Kinnison, so the buildd will push the tarballs into Rosetta?
[05:17] <lamont> my thinking is that they should just be one more file for dpkg-genpackage to deal with, and have the archive processing understand to just dump them on the side for lunchpad to grab.
[05:17] <Kinnison> lamont: exactly
[05:17] <Kinnison> lamont: well, dpkg-genchanges
[05:17] <lamont> Kinnison: the issue currently at hand is that all the langpack tarballs from the 64-bit architectures are missing .mo files
[05:18] <lamont> yeah, genchanges
[05:18] <Kinnison> lamont: Right. Currently we permit nominating an arch for arch_all, so I guess we can nominate an arch for langpacks
[05:18] <lamont> and the fact that our ia64 boxen are not the fastest boxes in the history of time, means that ia64 usually won, unless it was slow enough that  rosetta had already pulled the translations
[05:19] <lamont> they all do it because they want langpacks to include arch-specific packages as well.
[05:19] <Kinnison> aah right
[05:19] <lamont> yeah - it sucks more than arch all does
[05:19] <Kinnison> but not until July
[05:19] <lamont> fine by me.
[05:20] <carlos> Kinnison, yeah, please, we should talk about it :-)
[05:20] <lamont> (er, steaming pile of crap, btw.)
[05:21] <carlos> lamont, can you ban ia64 translation tarballs?
[05:21] <carlos> lamont, I don't think we have any ia64 exclusive binary with translations
[05:21] <carlos> so that way the problem is gone until Kinnison's code is ready
[05:23] <lamont> amd64 is also an issue, and ISTR there might be some amd64-specific stuff
[05:23] <lamont> but we could just plain ban both architectures - that'd be really simple for me.
[05:24] <daf> arch-specific translations
[05:24] <daf> wah!
[05:24] <lamont> daf: exactly
[05:24] <lamont> actually, that's really translations in arch-specific packages
[05:25] <daf> yarr
[05:26] <daf> the tricky thing is that it means processing the same sourcepackage/version multiple times to get all binary package mappings
[05:26] <carlos> lamont, I think it's ok to miss them until we fix the problem 
[05:27] <carlos> lamont, are they desktop applications or used a lot by people?
[05:27] <lamont> pool/main/i/ia32-libs
[05:27] <lamont> pool/main/i/ia32-libs-gtk
[05:27] <lamont> pool/main/i/ia32-libs-openoffice.org
[05:27] <lamont> pool/main/l/linux-kernel-di-amd64-2.6
[05:27] <lamont> pool/main/o/openoffice.org-amd64
[05:27] <lamont> is the amd64-specific package list for main
[05:27] <carlos> lamont, oh, that!
[05:27] <carlos> forget them
[05:27] <carlos> they come from the same source
[05:28] <carlos> from other applications, right?
[05:28] <carlos>  s/applications/architectures/
[05:28] <lamont> right.  I'll deal with this today then, and no more 64-bit translations until they can produce good ones
[05:28] <lamont> ia32-libs* are just copies of ia32 stuff
[05:28] <lamont> oo.o-amd64 nfc, but probably just a metapackage to get the right stuff happening\
[05:28] <carlos> lamont, as long as we get a version of the .pot and .po files is enough
[05:29] <lamont> linux-kernel-di-amd64-2.6 is the only one of any concern to me, and that's really a Kamion question
[05:29] <lamont> since I have no idea...)
[05:29] <carlos> lamont, don't think it will have too many translations....
[05:29] <lamont> dunno if any of those have any :0)
[05:30] <carlos> lamont, then ban that architecture :-D
[05:31] <lamont> yep.  that's what I'll do today, sometime within the next 2-3 hours
[05:31] <lamont> I'll let you know when it's done
[05:32] <carlos> ok
[05:32] <carlos> lamont, thanks
[05:33] <lamont> hrm... actually, I still need to strip them, I just need to not deliver the files to you.
[05:33] <lamont> that's even easier
[05:35] <lamont> carlos: hrm.. .you're about to get a flood of (maybe) new translations, compliments of the two i386 buildd's that were't being aggregated.  sorry
[05:36] <lamont> 1 in the next run, the other shortly after I make apache run on the buildd.
[05:36] <carlos> lamont, don't worry
[05:36] <carlos> as I said, we are not doing anything with breezy
[05:37] <carlos> so we ignore them until next month
[05:39] <lamont> np... was just an "oops.... INCOMING" warning
[05:45] <daf> breezy imports turn on Rosetta go BOOM
[05:46] <carlos> :-)
[06:30] <HiddenWolf> Isn't the entire goal of Rosetta to translate ubuntu, thus breezy?
[06:33] <mdke> it is ever more ambitious than that
[06:33] <mdke> its goal is to translate EVERYTHING
[06:33] <mdke> mwahahaha
[06:40] <daf> HiddenWolf: yes
[06:41] <daf> HiddenWolf: but we need to do some data administration before the breezy import
[06:41] <daf> HiddenWolf: currently we are busy working on the code
[06:45] <HiddenWolf> You'll not know where it breaks till you break it. :)
[06:51] <daf> ok, it'll probably work
[06:51] <daf> it's just going to be really busy for a couple of days
[10:33] <mpt> HiddenWolf: The Launchpad hierarchy navigation, and the Rosetta front pages, are both planned to become more streamlined over the next couple of months.
[10:35] <HiddenWolf> mpt, do you want me to spit out my ideas on the wiki somewhere, or can I just sit back?
[10:35] <mpt> what wiki?
[10:35] <HiddenWolf> no clue. Never used it. :P
[10:35] <mpt> Spitting them out here would work fine :-)
[10:36] <HiddenWolf> I'll check if I logged yesterday's rant
[10:39] <HiddenWolf> Woohoo
[10:39] <mpt> I was logged on too, so no repetition necessary
[10:39] <HiddenWolf> Ah.
[10:40] <HiddenWolf> Well, that covered the gist of it, and at least the spirit.
[10:41] <HiddenWolf> If you want people to help, present data in such a way that they'll feel and be useful as soon as possible, try to get every hurdle but registration out of the way.
[10:41] <mpt> yah
[10:41] <HiddenWolf> Usercase I worried about was the user/enthousiast who is convinced the current translations sucks, wants to click a button, and help out.
[10:42] <HiddenWolf> In that scenario, you either have a person looking to improve translations as a whole, so he should just be able to click "translate now" and get to work asap.
[10:43] <HiddenWolf> Or the person who is convinced the person who translated $packageX was on crack, so he'd like to be presented with the things he thinks are wrong, so he can improve them.
[10:43] <mpt> yep
[10:43] <mpt> One thing I'd like to present is a list of things you've been translating recently
[10:43] <mpt> so you can pick up where you've left off, without having to do bookmarks etc yourself
[10:43] <HiddenWolf> Perfect as a motivational tool also.
[10:43] <mpt> and also, a list of random things that need translating.
[10:44] <HiddenWolf> Just don't present them with a list of packages.
[10:44] <HiddenWolf> Everyone who is not a docteam or release maintainer wouldn't be interested in that. (bad grammar, 11pm, bear with me)
[10:44] <mpt> You mean a list of packages that might or might not already be translated?
[10:44] <mpt> Or a list of packages at all?
[10:45] <HiddenWolf> The interface you have right now is perfect for the techy, the maintainer and the nerd, what the more common/casual user needs, is either a list of packages that are not translated in $hislanguage, or no mumbling about packages at all, but just strings.
[10:46] <HiddenWolf> Searching on packages would be helpful, but not a solution in any way.
[10:47] <HiddenWolf> The way it is presented now in the interface is package  > details > language > translation -  This is illogical if the goal is translation, you're hiding it behind 2 steps. 
[10:48] <HiddenWolf> There should be an overview per language, with the option to check for packages needing love, check how far along the language translation is in general, or just get to translating the first untranslated string on the que
[10:48] <mpt> mmm
[10:48] <mpt> I'm actually writing the spec for that today
[10:49] <mpt> So I'll take that into account, thanks
[10:49] <HiddenWolf> That way you give people the option to click right through, get rid of information most users wouldn't care about, and taking out 2 steps.
[10:50] <HiddenWolf> I'd leave the current setup around tho, because it provides a clear overview for maintainers. :)
[10:52] <mpt> Well, maintainers should get a "You are maintainer of:" list
[10:52] <HiddenWolf> mpt, could you give me a heads-up on that spec once you get around to it? This thing really caught my interest.
[10:52] <HiddenWolf> mpt, true, but the same goes for any function.
[10:52] <mpt> HiddenWolf: No, sorry, the Launchpad wiki is developers-only
[10:53] <HiddenWolf> I bet a translator would love to know if a string in his/her pet package changed and needs revising.
[10:53] <HiddenWolf> mpt, I said heads-up, not carbon copy. :)
[10:53] <mpt> I'll keep the summary up to date at http://udu.wiki.ubuntu.com/RosettaEntityPages
[10:54] <HiddenWolf> i've got no intention of being on your back, getting excited about something that doesn't pay, and taking time away from my exams. ;)
[10:54] <mpt> heh
[10:55] <HiddenWolf> Microeconomics will be nasty, and I just fluked finance and accounting. I'd rather not add a few more to that list. :)
[10:55] <HiddenWolf> So good night to you. :)
[10:58] <mpt> goodnight, and have fun with the exams
[11:01] <HiddenWolf> economics, fun, well, yeah, perhaps the drinking afterwards. :)