=== verterok_ is now known as verterok === kiko is now known as kiko-afk [01:33] bzr is giving me an error when I try to push to LP: "Permission denied (publickey)." I recently created a new SSH key, but I've removed the old one and uploaded the new one. [01:38] Snova_: maybe a user name issue? [01:38] Snova_: what does ssh @bazaar.launchpad.net say? [01:38] Permission denied (publickey). [01:39] then i suggest you're not presenting the key you think you are [01:40] I think I found the cause of it... [01:41] I named the key id_snova instead of id_rsa. "ssh -i id_snova bazaar.launchpad.net" asks for my password, and works. [01:41] sounds plausible [01:48] Heh. Or it could have just been a stupid typo. "~/ssh" != "~/.ssh" [02:14] Oh me oh my, I just realized why my old version was being downloaded more than the latest stable at https://edge.launchpad.net/wxbanker/+download, LP lists my series below trunk! [02:14] Is there a way to fix this? [02:15] This seems incredibly unfortunate [02:18] well I've just deleted all my releases from trunk [02:18] that has fixed this === hggdh_ is now known as hggdh [02:47] mrooney|w: that sounds unfortunate. I'd file a bug on launchpad. [02:53] spiv: okay, I've filed bug 405597 as I couldn't find a dupe [02:53] Launchpad bug 405597 in launchpad "trunk is always listed at the top of the downloads for a project" [Undecided,New] https://launchpad.net/bugs/405597 [06:14] can I be made owner of a group if someone else has that position? [06:14] synic: talk to the existing owner, maybe? [06:14] synic: you mean of a team? [06:14] yup [06:15] can he give ownership to me? [06:17] He can. [06:17] There's a very well hidden link. [06:17] * wgrant searches. [06:17] I think they make you an admin of the team [06:17] isn't that sufficient? [06:17] no [06:18] hmm.. [06:18] I cannot change expiry of members [06:18] wait, I can, but I can't give others admin [06:18] In the 'Members' section of the team page, it says 'You are the owner of this team', with an edit icon. [06:18] There are two privileges granted to the owner: changing the owner, and making people (not) administrators. [06:18] ok [06:19] +reassign [06:19] it is a link at the bottom of the normal +edit [06:19] * wgrant hopes that Team Page 3.0 will make this less unobvious. [06:22] thanks for the info === Ursinha is now known as Ursinha-afk === allenap changed the topic of #launchpad to: https://launchpad.net/ | Launchpad is now open sourced: https://dev.launchpad.net/ | Help contact: allenap | Join https://launchpad.net/~launchpad-users | Channel logs: http://irclogs.ubuntu.com | #launchpad-dev is the developer channel === carlos_ is now known as carlos === MT- is now known as bluefoxity === bluefoxity is now known as MT- [10:19] dmentre: Did you figure out your Ubuntu Code of Conduct problem, or are you still having problems? === tonyyarusso is now known as Guest94079 [11:10] allenap: I still have the problem [11:12] allenap: Add hello by the way. ;-) [11:18] dmentre: Hello :) I'll go and look and see if I can find anything amiss. [11:19] allenap: thanks [11:22] dmentre: When I do a gpg --clearsign on the UCoC, the .asc file that's saved also includes the whole content of the UCoC. Do you get that too? I think you have to paste the full content of the .asc file into Launchpad, not just the signature. === noodles775 is now known as noodles775-afk [11:26] allenap: Thanks! As allways, the issue is between the chair and the keyboard. I copy/Paste from the terminal and did not see that the whole UCoC was copied. I'll retry this evening. [11:27] dmentre: Cool, I hope it works this time :) [11:44] jtv, dpm: Do either of you fine gentlemen have a moment to answer a user's question about translations? https://answers.edge.launchpad.net/rosetta/+question/78341 [11:48] allenap: I'll have a go at it, np [11:48] dpm: Thanks. === noodles775-afk is now known as noodles775 === mrevell is now known as mrevell-lunch [13:29] hi, is possible that the archive doesnt recognize sha256 keys? [13:30] I uploaded a packake more than 30 mins ago, and I received no ACCEPTED mails plus LP didnt publish any upload [13:30] so I'm wondering if my key is the problem [13:30] mars: ping? [13:31] cprov, ^^ [13:32] andv: this is probably related with LP not knowing your gpg key. [13:32] cprov, key used is C3E23AE6 [13:32] andv: lp does know how to handle SHA256 in uploads. I will check what's wrong, one sec [13:33] which is registered on LP [13:33] k ty [13:35] andv: which source did you upload ? [13:35] cprov, torbutton [13:36] cprov, version 1.2.1-1ubuntu2 [13:39] andv: found it, uploaded to the primary archive. [13:39] cprov, yes [13:40] andv: there was a dead-lock when closing the bug, I've never seen it before. [13:40] cprov, like it got stuck while processing the bug? [13:40] cprov, e.g while closing it [13:42] andv: no, more severe, it's was a legitimate dead-lock and pgsql aborts the transaction in this case. [13:42] cprov, and why it happened? [13:42] cprov, something was wrong somewhere? [13:43] andv: concurrent changes to one of the bugs in question [13:43] cprov, ok, is everything ok now or should I re-upload it? [13:44] andv: looking at it it seems perfectly acceptable to happen and we should retry the transaction. I will file a bug [13:44] andv: re-upload, please. [13:44] cprov, k [13:44] just a sec [13:46] cprov, done [13:51] andv: worked this time. [13:51] cprov, perfect, thanks [13:51] cprov, waiting for accepted mail then [13:53] cprov, source signer should receive accepted mail right? === salgado-afk is now known as salgado [13:53] cprov, also if the changelog email refers to someone else (e.g sponsoring) [13:53] andv: yes, Recipients: Andrea Veri , MOTU [13:54] cprov, received nothing yet, maybe a little lag from the mail server [13:55] andv: any of the signer, changed-by and maintainer with a LP preferred_email. [13:56] cprov, if I won't receive the mail gonna ping you to know what's going wrong [13:57] cprov, yesterday I didnt receive the accepted mail as well (and I was package's maintainer) [13:57] andv: I can't really debug this area myself, but I will certainly help you to find someone who can. [13:57] cprov, plus my mail is registered correctly as main one on my LP account [13:57] cprov, thanks [14:01] cprov, nothing yet, let me know when the guy who follows email area is up [14:02] andv: did you check your spam folder ? [14:03] andv: also I'm sorry for pasting your email address in a public channel, I shoudn't have done that. Apologies. [14:03] cprov, nothing in spam folder [14:04] cprov, np, I gonna receive some more spam which is not a problem [14:04] cprov, lol [14:06] andv: was the message delivered to MOTU ML and karmic-changes ? [14:06] cprov, let me see [14:08] cprov, nope, no mail on both -changes and -bugs [14:08] cprov, wait, yes on -changes [14:08] andv: I see the email on karmic-change.s [14:09] Right. [14:09] wgrant, yep, saw it now [14:09] had to refresh page === abentley1 is now known as abentley === vorian is now known as LadiesMan217 [14:10] cprov, maybe the problem is related to my LP account [14:11] andv: I'm not sure, 2 distinct emails were sent, one to you and MOTU (as mentioned above) and another one to the karmic-changes. The former is stuck somewhere. [14:12] cprov, and as I said yesterday I didnt receive the mail also if I was set as package maintainer [14:13] cprov, I'll try to change my mail on my LP account and try again on the new upload [14:14] cprov, if it keeps to not work gonna ping you again [14:14] cprov, thanks for your work and sorry for bothering [14:14] andv: okay, if it doesn't succeed please open a question on soyuz and we will deal with it. [14:14] andv: np, you are welcome. [14:15] cprov, I will [14:15] cprov, thanks a lot, good work [14:15] andv: I've just contacted you via LP, you should have received an email in your gmail acount. [14:16] cprov, seems to work === mrevell-lunch is now known as mrevell === LadiesMan217 is now known as vorian [14:32] I'm not sure if this is the right place to ask but, just to be sure, [14:32] assuming that my LP username is q-funk, then the resulting e-mail address would be q-funk@ubuntu.com if I understood https://wiki.ubuntu.com/UbuntuEmail correctly? [14:34] that wiki page mentions that aliases re created by an LP cron job, so I thought that this might be a good place to ask. [14:34] I believe that's correct, though I'm not an Ubuntu member myself (yet? :-)) [14:34] Q-FUNK, it's your-lp-ip@ubuntu.com [14:35] Q-FUNK, which is redirect to your main LP contact [14:35] s/ip/id/ I think :-) [14:36] yep [14:36] * lp-id === abentley1 is now known as abentley === abentley1 is now known as abentley [14:46] maxb: I became a member a couple of weeks ago. :) however, the mail alias doesn't seem to work. [14:47] Q-FUNK: Do what the wiki page says, I guess [14:48] maxb: yup. I mailed there 5 days ago already. still no response. [14:48] See the topic for the on-duty help contact - they can probably point you in the right direction [14:48] Q-FUNK, did you set your main contact addres on LP? [14:48] andv: yup. it's been there for ages. [14:49] Q-FUNK, as you know ubuntu mail addres is a redirection [14:49] yes, indeed [14:50] I've had the same contact address ever since my LP account was created in 2005. === abentley1 is now known as abentley [14:51] allenap: What should Q-FUNK do next? [14:52] Q-FUNK, you're right, your mail doesnt work [14:52] Q-FUNK, point me to your lp page [14:52] ~q-funk [14:53] 550 550 5.1.1 : Recipient address rejected: User unknown in virtual alias table (state 14). [14:54] Q-FUNK, Email: No public address provided. [14:54] right, not public, but it's set. [14:54] Q-FUNK, maybe that's the problem [14:55] Q-FUNK, anyway non-registered-users can't see your email [14:55] Q-FUNK, so what is the point having it not public? [14:55] andv: search engines catch it regardless if it's in plain view. [14:56] Q-FUNK, but anyway maybe you're problem is related to a not-public email [14:56] but of course I might be wrong [14:56] you should ask to an LP employe [14:57] andv: I was hoping to talk to one on this very channel, actually ;) [14:58] ^^ [14:58] Q-FUNK, add a bug on LP [14:58] and they will answer u back [14:59] ok, sending mail using the Contact link works, so we can rule the possibility of mail sending being disabled on LP. [14:59] andv: good idea. against which package or project? [14:59] would the generic launchpad project do? [15:00] Q-FUNK, generic LP project [15:08] hm. lousy connection, today :( [15:08] did allenap reply while I was disconected? [15:08] No, I guess he must be afk. [15:11] ok [15:18] Q-FUNK: Hi, I'll read the scrollback now. [15:18] allenap: ok. thanks :) [15:30] allenap: what can I do for you? [15:31] Hi herb, Q-FUNK became an Ubuntu member a couple of weeks ago, but his @ubuntu.com alias is not working yet. [15:32] hi herb :) [15:32] herb: The mta reports "Recipient address rejected: User unknown in virtual alias table (state 14)." [15:34] herb: we only have two theories so far: 1) username contains hyphen. 2) contact e-mail is set to non-public. [15:35] allenap: unfortunately that doesn't fall under my purview. [15:35] Q-FUNK: can you try asking on #canonical-sysadmin? [15:35] Q-FUNK: there should be someone there who can help you out. [15:35] herb: Thanks anyway. [15:36] allenap: sorry. :( [15:36] herb: ok. will do. thanks! [15:36] Q-FUNK: welcome [15:36] Q-FUNK: Sorry I wasn't able to help. [15:43] w10 === Ursinha-afk is now known as Ursinha === kiko-afk is now known as kiko === abentley is now known as abentley-lunch === sale_ is now known as sale [16:52] Any translations people here can answer Michael Trausch's question on launchpad-users@? "Translations branch keeps having status set to 'Merged'" [16:52] I feel like the answer is going to be "Twiddle this knob" or something simple like that, but I don't know it. === salgado is now known as salgado-lunch [16:53] jtv: ^^ ? === deryck is now known as deryck[lunch] === Guest94079 is now known as tonyyarusso [17:00] help.. I can login via bzr but I cannot download.. [17:01] I added my public ssh key to my profile.. but still getting a permission denied (publickey) [17:01] any suggestions? === noodles775_ is now known as noodles775-afk [17:30] evening, i am ashamed to ask, but is there a specific channel for the questions-ubuntu-section? === deryck[lunch] is now known as deryck [17:38] dpm: If you're free, kfogel ^^^ needs help from a translations dude. [17:39] allenap: thanks :-) [17:40] allenap: I responded in that thread. And now, trying to fetch you the URL of my response, I have apparently frozen my Firefox. Yay. [17:40] sinn3r: Hi there, I don't know what questions-ubuntu-section is, but you're much more likely to get an answer on #ubuntu. [17:41] kfogel: I love it when that happens :) [17:41] i am not looking for an answers... (ahm... yeah)... only for some people to shitchat about the questions ;) [17:41] sinn3r: What is the "questions-ubuntu-section" ? [17:42] ppl from here https://answers.edge.launchpad.net/ubuntu [17:42] ppl? === MrWordPress is now known as epsy [17:42] people [17:42] allenap: https://lists.launchpad.net/launchpad-users/msg05158.html [17:42] maxb: hey there [17:43] sinn3r: I think you're still probably better off in #ubuntu :) [17:44] sinn3r: If you want to discuss the underlying software powering that webapp, do it here. If you want to discuss the questions and answers themselves, #ubuntu is where you want to be. [17:44] maxb: okay thanks [17:44] Either way, you could do with being a bit more verbose in your explanations :-) [17:44] maxb: You rock, good answer :) [17:44] bye [17:46] allenap: kfogel: yeah, I saw the e-mail on launchpad-users when it was posted ^^, but I hadn't replied because I didn't know the answer (I believe only a LP Translations developer can answer that one properly). In any case, I think it might be related to this one -> https://answers.edge.launchpad.net/rosetta/+question/78238 [17:46] dpm: thanks [17:47] kfogel: I am ashamed to say that I know almost nothing about translations in LP :( [17:47] dpm: wow. Here I thought my announcement was late, and it turns out it was early :-). (for 2.2.7) [17:48] kfogel: :-) But that shows as well how well received this feature is, that people starts using it straight away! [17:48] dpm: yes === allenap changed the topic of #launchpad to: https://launchpad.net/ | Launchpad is now open sourced: https://dev.launchpad.net/ | Help contact: - | Join https://launchpad.net/~launchpad-users | Channel logs: http://irclogs.ubuntu.com | #launchpad-dev is the developer channel === abentley-lunch is now known as abentley === kiko is now known as kiko-fud [18:17] allenap: Thank you. I've been able to sign the UCoC! Many thanks for pointing out my error. === micahg1 is now known as micahg === salgado-lunch is now known as salgado === MT- is now known as profarius === profarius is now known as MT- === kiko-fud is now known as kiko [20:27] are udev inside the (karmic) ppa builders broken? [20:34] holzmodem: There is udev breakage affecting ubuntu itself, I imagine it could affect ppa builders too [20:34] ok thx http://launchpadlibrarian.net/29631353/buildlog_ubuntu-karmic-amd64.linux_2.6.31-4.24~lesswatts1_FAILEDTOBUILD.txt.gz [20:55] Are there any known issues right now with PGP keys or pushing to lp? [20:56] I'm a bit of a n00b, and nothing is working for me. === mac9416 is now known as macGPGPGPPNPNPN === macGPGPGPPNPNPN is now known as macSSH === macSSH is now known as mac9416 [21:02] mac9416: be more specific about what's not working? [21:03] maxb, output from bzr push lp:~mac9416/keryx/trunk: [21:03] The authenticity of host 'bazaar.launchpad.net (91.189.90.11)' can't be established. [21:03] RSA key fingerprint is 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89. [21:03] Are you sure you want to continue connecting (yes/no)? [21:03] Host key verification failed. [21:03] bzr: ERROR: Connection closed: please check connectivity and permissions [21:04] Sorry about the paste :-) [21:04] I have done bzr lp-login, uploaded my SSH public key. [21:06] Did you / were you able to type "yes" at the yes/no prompt? [21:06] maxb, yes [21:07] Ohmagarsh... [21:07] I didn't type yes, I just hit enter and thought it had assumed yes. [21:07] * mac9416 feels stupid [21:08] Thanks, maxb, now I need to go get some coffee :-) [21:08] n00b elixer [21:08] mac9416: is it working now? [21:08] mhall119|work, yes, and there's no need to tell excid3 how I got it to work :-P [21:09] lol [21:09] but I can tell crashsystems, right? === mac94161 is now known as macOut === NCommander is now known as Guest77821 [21:43] james_w: ayt? [21:54] Any Launchpad Translations experts here? Michael Trausch is being very specific in his email at https://lists.launchpad.net/launchpad-users/msg05163.html; someone who knows the system could probably answer him easily. [22:09] kfogel: Oh, hi there :) [22:14] mbt: are you jtv or mbt? (you both have real name "purple") [22:14] kfogel: I'm jtv [22:15] kfogel: I'm Michael Trausch :) [22:15] kfogel: Yeah, Pidgin does that, never did poke around to figure out how I could fix that. [22:15] ah [22:15] hi jtv and mbt [22:16] hi karl :-) [22:16] mbt, jtv: I think you two should talk to each other about mbt's problem :-) [22:16] which I will repeat here: [22:16] mbt: what's the problem? [22:16] jtv is the expert here? [22:16] Any Launchpad Translations experts here? Michael Trausch is being very specific in his email at https://lists.launchpad.net/launchpad-users/msg05163.html; someone who knows the system could probably answer him easily. [22:16] mbt: I think so. [22:16] looking that up... [22:16] If jtv is who I think he is, but I can't be sure, because his real name is also "purple". [22:17] which is strange because the client knows very well who I am afaik [22:17] Yeah... I wish Pidgin would read the GECOS field to get one's real name [22:17] I get a 404 on that link... [22:17] jtf drop the semicolon [22:17] jtv even [22:18] ah [22:18] another thing I would have expected the client to know :) [22:18] jtv: It isn't perfect, but it's better than having a whole different program running :) [22:19] mbt: which branch is it that gets set to Merged? The one you import from or the one you're trying to export from (which hopefully will start working very soon)? [22:20] lp:~mtrausch/alltray/launchpad-translations, when it has no LP Translations commits, after trunk had a commit. Of course, right now it is marked Development since there is a new commit on it, but I can't do anything with that commit at the moment but pound it in. [22:21] mbt: so that branch is the branch you're trying to export to? [22:21] I was wondering why LP would mark a branch merged that has no commits itself and has never been merged into anything (e.g.: bzr branch lp:alltray lp:~mtrausch/alltray/trunk followed by committing in trunk marks the latter merged, but it's not). [22:22] In addition to that, I have the problem of LP Translations commits not being terribly useful. :-P [22:22] mbt: so the branch with the problem is the one you had set up to export translations to? [22:22] Though that itself is a separate issue. I think I may have been confusing in my first email about my question, though... I _think_ it's a code hosting question. [22:23] Right, it would be marked merged when trunk's head no longer was the new branch's head. [22:23] mbt: is the branch you're having the problem with the one you had set up to export translations to? [22:23] Yes, it is the destination of a translations export. [22:23] And you were not importing translations from the same branch, or committing other stuff to the same branch, or anything scary like that? [22:24] Because as far as I've heard from IS, the cron job that does the exports to branch wasn't set up until about 3 hours ago. [22:24] No, the destination for LP Translation export was left alone after it was branched from trunk (until today when LP translations committed to it) [22:24] And after LP Translations committed to it, it was marked Development again (just prior to that, and since I branched it originally, it was "Merged") [22:26] You branched it originally... does that mean you created the branch by branching off an existing branch? [22:26] Yes, I branched it from lp:alltray [22:27] Then my first guess would be that bzr figures out that there are no differences with that branch, and marks it Merged to indicate that. [22:27] Yes, I'm guessing that's what Launchpad does, though I would think that it would leave it alone until it sees a merge from one to the other in its history [22:29] I can't guess what goes on in there... It doesn't sound like this unexpected Merged state had anything to do with the Translations app, and happened before the translations commit happened. [22:29] Is that right? It's very late here and I'm not too good at taking up information just now. [22:29] That would be correct. The Translations-specific part of my question pertains to that commit though, which I can't actually merge. :-P [22:30] Translations apparently didn't consider that I'd imported translations manually in lp:alltray from it already, and so trying to merge its output results in a massive set of conflicts [22:31] From "it" is from the other branch? [22:31] Or from Translations? [22:33] From Translations. Translations *knew* I committed the new translations (they are now green in the UI), but it didn't take that into account when it made the commit to the export branch. [22:33] The involved branches are listed on https://code.launchpad.net/alltray [22:37] Anyway, yes, the exports to a branch completely overwrite any previous versions of the same files in the branch. [22:37] Those may well conflict with something you have somewhere else, which is why we implemented a commit-to-branch but no merge. [22:38] If we try to resolve conflicts automatically, there's just too much risk that we'll make the wrong decision for you! [22:39] mbt: sorry for the delay; I think my connection did something strange. [22:39] It'd be nice if there were an option to do that; it should be able to be told which branch to merge before committing, and alert and abort on a conflict. If it were done that way in this case, it would have been conflict-free, because it would have made the diff after merging mainline [22:39] That's okay, I can certainly understand connection issues :) [22:40] Because if there are no changes that LP Translations is completely unaware of, that would be a safe transaction [22:40] Not sure how others would like to use it, but what my thought for it (it's only utility I can think of) is to make translations in the repo seemless to merge. [22:43] This problem spans different "worlds": on the one hand text files, with merge conflicts that won't obey message boundaries, and on the other hand messages in the database. We can't recreate the same file we imported _exactly_: there may be differences in message order, different whitespace and line breaks, strange combinations of changes and so on. [22:43] If there is a conflict, there's pretty much nothing we can do to resolve it textually without risking doing the wrong thing. [22:43] True, but I would imagine that since it can parse them, it can go "I knew of all changes" and commit the right thing [22:44] (Not to mention the enormous time this would take to develop and the risk of further bugs!) [22:44] Does that make sense? [22:45] Well, I'm confused on there... LP already knows how to read a PO, so it can determine if two POs are equal already (it does that to compute the differences between what's in the source branch and LP Translations, right)? [22:45] For some definition of equal. [22:45] Definitely not the same as what bzr considers equal. [22:46] Well, right. But it can safely decide whether its changes can be committed safely or not, at least when the destination branch matches Translations' view of the source branch [22:46] At least, it would seem so to me. Admittedly I haven't looked at LP's source yet (been on my list, not enough time...) but generally speaking, it would seem that way. [22:46] It is possible that I am poorly articulating the idea. [22:48] I don't think so, but what I'm saying is it's one of those cases where the perfect solution would be one we wouldn't have had time to build. [22:48] If I had known when LP was going to commit, I would have already merged it. But I don't want to have to continue to merge it at every commit to trunk, that woudl be tedious [22:48] *however* [22:48] there is a completely different solution. [22:48] It _is_ possible to import from and export to the same branch. [22:49] True, and that can always be reverted, but the question then becomes, when does LP Translations compute what diff it is going to commit? [22:49] It never does. I was just typing the explanation here. :) [22:50] Would there ever be a chance that it would compute that, I would commit, and then it would commit the wrong thing because of delay between steps 1 and 3 in that list? [22:50] That's just what I was typing. :) [22:50] When the export-to-branch script detects that there are changes to the branch that haven't been processed yet, it skips the export. [22:51] Ahh, so for the use-case I want, it should be safe? [22:51] Yes. There's always going to be nasty corner cases, and of course if you're always committing to the branch when LP tries to do the export, the export doesn't happen. But in principle, it should be pretty safe. [22:52] One particular thing to note about it is that it _is_ possible that the latest changes you wrote to your branch are still waiting on the translations import queue while the export happens. [22:52] Okay, only other question then is this: How many times a day will an export commit happen when there are changes to commit? (Or does it run every time, regardless?) [22:52] For now, once a day. We still have to see how it scales. [22:53] We'll tweak it later. [22:53] That shouldn't be an issue, translation is only happening in LP; I won't actually make any more changes in the branch once the last po actually imports (it has been stuck on "Needs Review" for days) [22:53] Well hopefully you won't be the only user of this feature :) [22:53] Oh, you mean the corner cases. Sorry. [22:53] LOL [22:54] Yeah, I don't manage translations manually, I only know English. :-P [22:54] I thought you were talking about the scalability! [22:54] Anyway, there's one corner case that could be a bit scary though not actually harmful: you could commit a translations change to the branch, [22:55] and then the export could happen while the changed file was sitting on the translations import queue. [22:55] In that case, that export would commit a file without your latest change. [22:56] Assuming that your change is imported successfully, it would re-appear in the next export run. [22:56] Ahh, that shouldn't happen really, and if it does, I can fix it quickly. Though, I do have one that I have to do manually: en_US.po [22:56] https://translations.edge.launchpad.net/alltray/+imports <-- Can you "unstuck" that last one in that list? [22:56] mbt: you can't translate to en_US in Launchpad. [22:57] Odd. Why not? en_US contains the English UTF-8 translation [22:57] Since gettext requires the strings be ASCII, I had to do that to display Unicode [22:57] Then what language are you translating from? === salgado is now known as salgado-afk [22:57] English ASCII (e.g., non-Unicode, 7-bit transliteration, "C" locale) [22:58] I never heard of that being required... I'm pretty sure Launchpad has no problem with UTF-8 in msgids, because I used that to test a bug fix recently. [22:59] The GNU docs state that it has to be ASCII, and I did have strange issues using UTF-8 in the source when generating the template file. [22:59] I believe that the suggestion to use en_US "locale" for UTF-8 was on the gettext ML archives, though I could be wrong. [23:00] That could be for the reason that an untranslated program runs in the C locale, which is supposed to be ASCII as I understand it. [23:00] * jtv tries with a Thai letter in a msgid [23:01] Perhaps I'm taking the purist view, though, or maybe I have a local bug somehow. [23:01] Well as long as the locale actually _matches_ what's in the file, it's hard to imagine there being a problem with that... [23:01] So, anyway, I assume strings are C locale, and I put en_US.UTF-8 in its own file. [23:01] That way I can use ‽ or … or π, etc. [23:02] And just show transliterations in the C locale for those characters. [23:02] Right. I think the best way to deal with that in Launchpad would be to use en_US.po as your template. [23:02] Wouldn't it then erase the content of the translation, since templates are supposed to only have msgids? Or would it ignore that? [23:03] The msgstrs on a template are ignored. They need to be there for the file to be well-formed, but apart from the header, we don't care what's in them. [23:03] And LP never regenerates that file when committing to a branch? [23:04] Hmm... actually using en_US.po as the template doesn't solve the problem. Excuse me, it's late here and the brain has gone to bed. [23:04] I can understand that :) [23:04] (The template is not exported as part of commit-to-branch) [23:04] https://translations.edge.launchpad.net/alltray/trunk/+pots/alltray/en_GB/14/+translate <-- that is an example of what I use the en_US template file for [23:04] rather, not template, translation [23:05] If you clicked on that, though, refresh it, because it wasn't done lol [23:06] That said, I think I just found a way around that, maybe. [23:07] (BTW I just tried and msgfmt -v -c doesn't see anything wrong with a UTF-8 character in my msgid, whether in a template or a translation) [23:07] (I did have to specify the encoding, of course) [23:08] I don't recall what my exact issue was. I know I had one, and that fixed it. [23:08] * jtv hates encodings [23:09] jtv, I used to, too. [23:09] As long as there's a choice, it means there's no single right answer [23:09] Now that there is 7-bit ASCII and UTF-8 that are really the only terribly important ones, I am happy :) [23:10] I think the classic C UNIX "locale" will probably always be 7-bit ASCII, even though UTF-8 probably is the only thing that really matters widely anymore... Even just other transformations like UTF-16 or UTF-32, but they're all easy and define the same character set just with different representations [23:11] * jtv remembers web apps that use different single-byte encodings for data storage depending on the visitor's locale... and then a friend had to mix German and Thai [23:11] Eww. [23:12] Well one of the great things about UTF-8 is that everything that works with single-byte encodings does something reasonable with UTF-8, and almost everything that works with ASCII will behave. [23:12] Maybe en_US should be un-special cased. It seems happy to store data for it, it just won't show up on the front page: https://translations.edge.launchpad.net/alltray/trunk/+pots/alltray/en_US/+translate?start=30 [23:12] (Not counting char being signed on some platforms and unsigned on others etc.) [23:13] IIRC it's not really special-cased ("en" is though), but marked as a language you probably don't want to translate to. [23:14] Yeah, though en_GB shows up on the front page [23:14] There may be a factor of sympathy for the British who had their language "stolen" from them. [23:15] I told my gf to manage en_GB. She runs her system in that locale, anyway. Loves the way they spell their words. [23:15] One reason for not showing en_US is that we don't want to encourage unnecessary fragmentation, or translation from other languages than English (which we definitely don't support) [23:16] * jtv sometimes types "colour" in config files [23:16] Maybe they could show it as "Unicode English" or something to make that clear? I don't know. [23:16] I pick on my gf for it, because she writes "colour" or uses s instead of z---yet her whole life, has lived here, in Atlanta lol [23:17] Well it's definitely given me an insight into why people might want to have an en_US.po. Internally though we abstract it all away and do everything in Unicode. (Not even an encoding—we don't care) [23:17] That's funny... never heard of that happening before [23:17] mbt: noah webster (who broke american spelling) was a yankee [23:18] Yeah, that makes sense, Python doesn't really give you an idea of charsets working with strings, does it? [23:18] No. It takes some getting used to, but once you're in Unicode, you're fine until you have to encode again. [23:20] Anyway, that cock I just heard outside is a definite sign it's too late. I'll have to go offline for a bit! [23:20] A-ha. I misremember what I read in the GNU doc, but was not entirely off: GNU recommends 7-bit ASCII because POSIX does not define the C locale's character set, and ASCII is considered to be safe (it is left up to the OS) [23:20] Oh, en_US. Rooster, right? [23:21] Ahhhh [23:21] jtv: For stupid Americans, yes, "rooster". The other is slang here. [23:21] So for non-stupid Americans it's still "cock"? [23:21] And most stupid Americans don't remember that it has a non-slang meaning. [23:21] * jtv tries to remember [23:21] Well, no, we say rooster, but non-stupid Americans will understand what you mean. [23:22] Stupid Americans will assume a very different meaning. [23:22] you call someone a rooster? [23:22] Well fuck them. :-) [23:22] hi thumper [23:22] hi jtv [23:22] "cock" is slang for "penis" in the US. [23:22] yes, I know, thanks. :) [23:23] I'm just too tired to think of the right word... I originally wrote a different bird, can't even remember which [23:23] Maybe crow, for obvious reasons [23:23] That said... imagine a program written in en_GB that would benefit from translation into en_US.... [23:23] that word is a perfect example. [23:23]