[07:08] <dpm> good morning all
[07:47] <dpm> hi all, could someone tell me if going to http://91.189.93.101/ you see a localized help page?
[07:51] <TLE> dpm: it triggers a download and it isn't localized
[07:53] <dpm> TLE, hm, weird. What is it trying to download? Have you got language preferences set in your browser? And does http://91.189.93.101/index.html.da load for you?
[08:01] <TLE> it is downloading a page that looks as if it is a html page with the desktop guide, non localized or styled
[08:01] <TLE> that link does the same
[08:01] <TLE> let me check on the language preferences
[08:02] <dpm> which browser are you using?
[08:02] <TLE> chrome
[08:02] <TLE> I would assume that the language preferences are set, the gnome release notes loads the danish version
[08:03] <dpm> hm, strange, the direct link works for me in Firefox and Chromium
[08:04] <dpm> TLE, there is a <html lang=> attribute on the page it downloads. Is it at least set to "da"?
[08:05] <TLE> let med check
[08:05] <TLE> no wait sorry, the long link loads
[08:06] <TLE> and it has lang set to da
[08:06] <TLE> maybe we just don't have anything to localized
[08:06] <TLE> if I switch to german it shows something in german
[08:07] <TLE> so that seems to be tha case
[08:07] <TLE> but the short link still downloads
[08:10] <artnay> dpm: works for me
[08:11] <dpm> thanks for testing TLE. I don't quite understand why the short link does not work... I'll have to investigate
[08:11] <kelemengabor> dpm: works for me too
[08:11] <dpm> artnay, kelemengabor, thanks. Does the short link work for you guys?
[08:12] <artnay> dpm: just the ip? yes, it gives me the localized version
[08:12] <kelemengabor> I tried the short link
[08:12] <artnay> I'm using chrome as well
[08:12] <kelemengabor> that works
[08:14] <dpm> it might have to do with the .da extension
[08:14] <dpm> I'm using the same method to load localized pages as the browser home page in Firefox
[08:15] <artnay> dpm: do you plan to update the localizations before nonlangpack freeze?
[08:15] <artnay> dpm: could be helpful for ubuntu-docs translators
[08:15] <dpm> I remember the .pl and .tr versions had problems in the past, as the server was interpreting them as Perl files and something else
[08:17] <dpm> artnay, that was the idea, but I'm not sure I'll have time. I want this to be fully automated, and I asked the docs team a few days ago on the mailing list to use automatic exports, so that translations are committed daily, but they haven't come back to me yet
[08:22] <TLE> dpm, kelemengabor: Do you have a few secs to talk about the natty lang packs
[08:22] <dpm> TLE, sure
[08:23] <kelemengabor> sure
[08:23] <TLE> 2 sec
[08:24] <TLE> ahh actually 2 min, I just got an email on the matter
[08:24] <TLE> I'll get back to you
[08:24] <dpm> ok
[08:26] <kelemengabor> dpm: what's up with those?
[08:26] <dpm> kelemengabor, with those what?
[08:26] <TLE> ok the problem is that the latest natty language packs are not very good, major problems with the docs
[08:27] <kelemengabor> dpm: natty langpacks
[08:27] <TLE> two languages have tested
[08:27] <dpm> kelemengabor, I think you wanted to ping TLE, he's the one who wants to talk about them :)
[08:27] <TLE> so the issue is whether these problems are regressions, which will determine if we release them
[08:27] <kelemengabor> no much love for natty anymore
[08:27] <dpm> TLE, what are the major problems with the docs?
[08:27] <kelemengabor> dpm: argh, I'm a genius :\
[08:28] <dpm> np :)
[08:28] <TLE> from discussion with kelemengabor it seems that they are not regressions, but I'm currently in dialog with the german tester as well, will get back to you when I know what the verdict is there
[08:30] <dpm> TLE, yeah, that sounds like a good plan. As the one who mentioned the problem, it makes sense that he checks if it's actually a regression. It could also well be that the docs upload previous to the langpack export was done without pulling the latest LP translations
[08:31] <TLE> yeah, but he is actually not able to test for regressions him self, but he has asked for feedback from other translators
[08:31] <dpm> ah cool
[08:32] <kelemengabor> dpm: as I wrote on the QA page, the docs sucks because of bug #794426
[08:33] <kelemengabor> and probably always did... so no regression here
[08:35] <dpm> kelemengabor, so does the bug affect all languages with low coverage, or only Danish?
[08:37] <kelemengabor> dpm: its not only about coverage (that too), but basically yes
[08:37] <kelemengabor> the other problem is that there is a legal.xml which is included from a lot of pages, but not translated to any languages
[08:38] <kelemengabor> so the wrong linking strikes even those who have high coverage
[08:38] <kelemengabor> http://people.ubuntu.com/~kelemeng/pix/langpackup.png
[08:38] <kelemengabor> like this
[08:39] <dpm> bummer. I wonder why no one other than the Danish guys complained about this before. I would have thought the Spanish translators and others with complete translations would notice
[08:39] <kelemengabor> as a result, even those languages with high coverage have pages that do not appear translated
[08:39] <kelemengabor> and of course, fixing manually this broken link resulted in a perfectly translated help :\
[08:42] <dpm> kelemengabor, so do you know if this still affects precise (i.e. are we still using cdbs + debhelper.mk to build the docs)?
[08:43] <kelemengabor> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ubuntu-docs/oneiric/view/head:/debian/rules
[08:43] <kelemengabor> this one does...
[08:44] <kelemengabor> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-docs/precise/view/head:/debian/rules
[08:44] <kelemengabor> this too
[08:45] <kelemengabor> but... IIRC there is something else in the toolchain that makes this not appear anymore
[08:45] <TLE> going to the lab now, get back to you later
[08:50] <kelemengabor> dpm: ah got it, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/cdbs/precise/revision/111
[08:50] <kelemengabor> the buggy code part was dropped after natty :)
[08:51] <dpm> ah, pheeew! :)
[08:51] <dpm> thanks for investigating
[08:51] <kelemengabor> indeed :)
[08:53] <kelemengabor> so, what do we say about #794426? I'm thinking about wontfix for g-u-d and fix released for u-t and cdbs...
[08:56] <trijntje> Is there anything I can do to get some attention to bug 957746  ?
[08:56] <dpm> kelemengabor, agreed. Pity that we haven't got a better way to mark that the bug is still present in an earlier version, but 'Won't fix' is the right status, +1
[08:57] <dpm> trijntje, I'd suggest you talk to pitti on #ubuntu-desktop, as he's the maintainer
[08:57] <kelemengabor> dpm: explaining in a comment can work though :)
[08:57] <dpm> :)
[08:58] <trijntje> dpm: thanks, I'll try that!
[08:58] <dpm> trijntje, cool, let me know how it works out
[09:02] <dpm> I've added a comment to the bug too
[09:03] <artnay> are some titles hardcoded into ubuntu-docs? for example the title "Dash" at http://91.189.93.101/unity-introduction.html doesn't exist on ubuntu-docs template
[09:04] <artnay> this is problematic since we've translated dash as "Unity menu", now we have both dash and "unity menu" in docs
[09:05] <dpm> artnay, I'm not sure. I can see it translated on http://91.189.93.101/unity-introduction.html.es
[09:05] <dpm> Or http://91.189.93.101/unity-introduction.html.sl
[09:05] <dpm> is that what you mean?
[09:06] <kelemengabor> https://translations.launchpad.net/ubuntu/oneiric/+source/ubuntu-docs/+pots/ubuntu-help/fi/2435/+translate
[09:07] <kelemengabor> maybe this is it?
[09:07] <artnay> dpm: yes
[09:07] <artnay> kelemengabor: could be although the current page is missing "the", it's only "dash" (which is non-existent on template)
[09:08] <kelemengabor> artnay: interesting, because it is translated for me like "The Dash"
[09:09] <kelemengabor> it's time to ask dpm where did he got the original and the translations :)
[09:09] <artnay> kelemengabor: http://i.imgur.com/LGiyW.png
[09:11] <kelemengabor> artnay: the latest&greatest upstream has The Dash too: https://translations.launchpad.net/ubuntu-docs/precise/+pots/ubuntu-help/fi/2555/+translate
[09:11] <trijntje> dpm: I'll try building a package with 'nl complete', but as far as I know the example package uses 'de complete', and also has the same bug
[09:12] <dpm> trijntje, ah, ok. Feel free to comment on the bug and mark it as 'New' again
[09:13] <dpm> Gwaihir, were you guys hit by that bug when you created the Italian ISO? ^^
[09:13] <artnay> kelemengabor: true, maybe http://91.189.93.101/unity-introduction.html uses natty translations for some parts
[09:14] <dpm> artnay, kelemengabor, I've got a checkout of lp:ubuntu-docs/precise, that's where I'm generating the localized versions from
[09:14] <dpm> I suspect that the docs team did not update the template in the Ubuntu source package in LP
[09:24] <kelemengabor> dpm: I don't have permission to mark #794426 as wontfix in Ubuntu, could you help me out
[09:24] <kelemengabor> ?
[09:24] <dpm> bug 794426
[09:26] <dpm> kelemengabor, I don't have the permissions, either. So I'd recommend asking on #ubuntu-bugs or leaving it as confirmed for the bugsquad or the desktop team to update its status
[09:28] <dpm> ok, uploaded an updated template on https://translations.launchpad.net/ubuntu/precise/+source/ubuntu-docs/+imports
[09:28] <kelemengabor> okay, I'll leave it for now
[09:28] <Gwaihir> dpm, which bug?
[09:29] <dpm> Gwaihir, bug 957746
[09:30] <Gwaihir> dpm, nope, I do not recall this problem
[09:30] <Gwaihir> have to check with xdatap, but I didn't see that bug
[09:32] <dpm> ok, thanks!
[12:41] <kelemengabor> dpm: is it normal that the last data point is 03-20 here: http://91.189.93.77/stats/precise/hu
[12:41] <kelemengabor> or 21
[12:43] <dpm> kelemengabor, good catch, I've noticed it too just today. I had to re-deploy the whole webapp when the previous cloud instance died during maintenance, and when I set it up, I made a mistake when writing the cron job that updates stats. But no worries, all data is safe and I'll be updating it this evening :)
[12:43] <kelemengabor> thanks :)
[13:02] <trijntje> dpm: bug 957746 was caused by the use of unetbootin to put the image on a usb stick
[13:13] <dpm> thanks for the update trijntje
[14:26] <dpm> kelemengabor, ok added a todo item to recover the data on the stats server - https://trello.com/board/translations-team/4f621c87861db54230b9ca39
[14:26] <dpm> will do it in a few hours
[14:32] <kelemengabor> dpm: this reminded me that I wanted to do something this week - added it :)
[14:33] <dpm> kelemengabor, ah, cool, thanks :)
[14:34] <dpm> kelemengabor, ah, your action reminds me I wanted to show you something else, just a sec...
[14:41] <dpm> kelemengabor, http://pastebin.ubuntu.com/903993/
[14:42] <kelemengabor> yay!
[14:43] <dpm> I know you'd like it :-)
[14:43] <dpm> *knew
[14:44] <kelemengabor> added another task to myself
[14:45] <dpm> :)
[14:46] <kelemengabor> and now back to some release-notes... ;)
[14:46] <dpm> :)
[14:51] <artnay> is there a reason why translations from "Launchpad Translations Administrators" are preferred over translations that have been done (read: fixed) later by users? this happens in ubuntu-docs natty -> oneiric -> precise transition and the reason seems to be license compatibility... for example https://translations.launchpad.net/ubuntu-docs/precise/+pots/ubuntu-help/fi/+translate?batch=10&show=all&search=Est%C3%A4%C3%A4+muita+henkil%C3%B6it%C3%A4+k%
[14:52] <artnay> it's pretty frustrating to fix all those after they've already been fixed in natty/oneiric.
[14:54] <artnay> and +details page doesn't offer any way to filter translations made by LTA: https://translations.launchpad.net/ubuntu-docs/precise/+pots/ubuntu-help/fi/+details
[14:58] <dpm> artnay, looking...
[15:01] <artnay> dpm: thanks
[15:33] <dpm> artnay, sorry, it might take me a while, but I'll look into it today
[15:35] <artnay> dpm: no hurry, I just leave it like that for a while. will fix it later.
[15:45] <dpm> artnay, I cannot see anything in the link you gave me. Is this the correct link? -> https://translations.launchpad.net/ubuntu-docs/precise/+pots/ubuntu-help/fi/+translate?batch=10&show=all&search=Est%C3%A4%C3%A4+muita+henkil%C3%B6it%C3%A4+k%
[15:47] <artnay> dpm: try this https://translations.launchpad.net/ubuntu-docs/precise/+pots/ubuntu-help/fi/+translate?batch=10&show=all&search=Prevent+other+people+from+using+your+desktop+when+you+go+away+from+your+computer.
[15:48] <dpm> I think the reason why translations in LP are being overridden is because the docs team is importing PO files from the bzr branch, but does not export them often. So what I believe it happens is:
[15:48] <dpm> - Someone fixes a translation in LP
[15:49] <dpm> - An out of date translation is uploaded/committed in the docs package/upstream project
[15:50] <dpm> - Source package uploads/commits have got preference over translations done in Launchpad
[15:50] <dpm> - Translations in Launchpad are demoted to suggestions
[15:53] <artnay> dpm: that would suggest that translation sharing isn't working, no? the upstream package should have the updated translation. if the docs team doesn't incorporate the fixed translations into source package before creating a new branch, this happens, right?
[15:58] <dpm> translations sharing is working. The problem happens when there is an upload or commit of an outdated translation, which then takes precedence, as LP thinks the outdated one is the current
[16:00] <artnay> dpm: right, I hope the -docs team will take a note
[16:42] <ttoine> hi
[16:42] <ttoine> is there someone from the french ubuntu translation team ?
[16:43] <dpm> ttoine, if no one answers, you might also want to try on #ubuntu-locoteams
[16:44] <ttoine> dpm, thanks
[17:06] <dpm> artnay, kelemengabor, ok the ubuntu-docs template in Ubuntu is now in sync with the one upstream. Now "The Dash" translations appear on https://translations.launchpad.net/ubuntu/precise/+source/ubuntu-docs/+pots/ubuntu-help/ca/2509/+translate and
[17:06] <dpm> https://translations.launchpad.net/ubuntu/precise/+source/ubuntu-docs/+pots/ubuntu-help/ca/2511/+translate
[17:08] <dpm> With the help from the docs team I can now set up http://91.189.93.101/ to be updated daily with new translations. If anyone needs a more frequent refresh, feel free to send me PO files and I can then refresh the HTML pages with the new translations
[17:18] <artnay> dpm: will you do that tomorrow or /now/? :-)
[17:19] <artnay> dpm: you can call it a day now, this is a great addition
[17:20] <dpm> artnay, I'll set it up tomorrow, as today translations are already up to date :) Then next translations export happens some time tomorrow morning.
[17:21] <dpm> but as I say, if anyone has got PO files that you'd like me to generate HTML for in between daily updates, feel free to send them my way
[19:52] <roadmr> kelemengabor: hey, are you around? :)
[19:53] <kelemengabor> roadmr: yes
[19:54] <roadmr> kelemengabor: we got some trouble with setting up i18n support in checkbox-qt, follow-up from last week
[19:55] <roadmr> kelemengabor: I'm calling bindtextdomain("checkbox","");
[19:55] <roadmr> kelemengabor: we're just not too sure about leaving the localedir parameter blank, is this OK?
[19:55] <kelemengabor> hm, good question
[19:56] <kelemengabor> IIRc I never saw it empty
[19:58] <roadmr> kelemengabor: hehe :) so on local tests (i.e. I put a test .mo file in /usr/share/locale-langpack/en_CA/LC_MESSAGES/checkbox.mo and run *from my branch*), then it picks up the translations OK
[19:58] <roadmr> kelemengabor: if OTOH I build, then install a package, and put the test .mo in /usr/share/locale/en_CA/LC_MESSAGES/checkbox.mo, then it *doesn't* pick them up
[19:59] <roadmr> kelemengabor: however, the Python portion of the code *does* pick up all the translations, so I'm thinking it has to do with our call to bindtextdomain
[19:59] <roadmr> btw, ctf here is the one who found this problem; I was happy to see it work in the source branch, but he actually tested a package, smart thing to do since it fails :(
[20:00] <kelemengabor> well, then don't do that
[20:01] <kelemengabor> http://www.gnu.org/software/gettext/manual/gettext.html#Triggering says it has to be there, but does not speak about what happens otherwise
[20:01] <roadmr> kelemengabor: hehe :) makes sense :)
[20:02] <roadmr> kelemengabor: for instance, unity-2d points that to their INSTALL_DIR and some other stuff
[20:03] <kelemengabor> usually, it is $datadir/locale
[20:10] <roadmr> kelemengabor: I see the checkbox .mo files in /usr/share/locale, I could try arbitrarily pointing it there but I want to make sure I do the right thing
[20:10] <kelemengabor> that's appreciated :)
[20:10] <roadmr> kelemengabor: btw, thanks so much for all the pointers on getting intltool working with the .cpp files; with the Makevars magic and the POTFILES.in thing, it worked great :) (now the problem is in *my* code heh)
[20:11] <kelemengabor> the problems is that I don't know much about Qt myself
[20:12] <roadmr> yes, the build infrastructure is a bit crazy, so I don't have stuff like automake/autoconf and so on
[20:12] <roadmr> basically I just qmake; make
[20:12] <roadmr> prior to dh_build
[20:21] <kelemengabor> roadmr: one more thing, I have checked out your branch, and noticed that there are some strings marked for translation with tr() in qt/frontend/qtfront.cpp, and you do not pass this function to the XGETTEXT_OPTIONS variable in Makevars
[20:21] <roadmr> kelemengabor: oh! the branch we're testing replaces that with checkboxTr and catches a few more stray strings; we were just testing before merging to trunk
[20:21] <kelemengabor> cool
[20:22] <roadmr> kelemengabor: ok so if I arbitrarily set localedir to /usr/share/ it works, but I'm not too happy with it :/
[20:25] <kelemengabor> don't worry, many packages do so... *usually* they do not break :)
[20:25] <roadmr> kelemengabor: ok, so we'll try that as a workaround and try to figure out the right way (tm) later
[20:28] <kelemengabor> also, why is it necessary to define custom translation functions and not to use stock ones?
[20:30] <roadmr> kelemengabor: by default, Qt uses Qt::Translate (or somesuch), but that doesn't pick up gettext message catalogs; it uses Qt's own l18n mechanisms
[20:31] <kelemengabor> oh
[20:31] <roadmr> kelemengabor: they provide a mechanism to replace those calls with a custom function, it's the approach I've seen for Qt apps that need access to gettext catalogs (unity-2d and vlc; admittedly a pretty small sample)
[20:31] <kelemengabor> then it makes sense, thanks
[20:32] <roadmr> kelemengabor: further, the replacement function can't just be "gettext" (which would be easy) because the parameters qmake puts in place are different; so a wrapper is needed. But if you look at our wrapper, it's very thin, so no much complexity added
[20:33]  * roadmr is no expert either; learned everything about i18n in the past few days :)
[21:21] <roadmr> are .mo files cached somewhere? we tried removing our .mo file and we're still seeing the translated messages %)
[21:29] <roadmr> never mind, we found the problem :) a stray .mo file was getting picked up.