[01:05] hi, I'm trying to set up automatic translation import, but I can't get it to work. [01:05] What is the "domain" mentioned here?: https://help.launchpad.net/Translations/ImportingFromBazaarBranches [01:06] is it from bzr branch lp:domain ? [01:07] also, is the first import automatic or does it need to be reviewed? How long does it take? [01:11] KIAaze: 'domain' in the translations context normally refers to a gettext domain. [01:12] I think it should be automatic. [01:13] ok, do you know how I can find out the domain used? [01:13] I have .pot files automatically created by gambas [01:14] I think the .po files should normally be in a directory named the same as the domain, but I don't really know. [01:14] how would launchpad know the domain to use anyway when searching for .pot files? [01:45] hmmm, 2 hours since merge req and still no diff, is something broken? [02:05] Meths: can you give me a name/link/whatever to identify the req in question? [02:06] spm: https://code.launchpad.net/~j-corwin/openlp/presentations/+merge/12625 [02:32] Hi [02:32] I cant figure out how to install a package from a launchpad apt [02:32] even after reading the guide [02:34] diones: which version of Ubuntu are you running? [02:35] jaunty [02:35] Meths: I can clearly see it's not working for you; but the scripts in Q are (apparently...) working fine. I'll have to grab one of the relevant devs atm, and they're all afk for now. [02:37] spm: Thanks, off to bed anyway so no rush. One thought, he may have changed a binary so if it tries to diff that it may cause problems, not sure how launchpad filters binaries. [02:37] that's a darn good question actually. no idea... :-) [02:38] Meths, spm: Binaries do crash that script right now, I believe. [02:39] There's a bug on that. [02:39] irritatingly then, it's not letting me know it's crashed. :-( [02:39] oops, do we just wait for the fix or is there a workaround? [02:40] spm: Not sure how far it crashes. [02:41] Bug 436325 [02:41] Launchpad bug 436325 in launchpad-code "Diffstat generation chokes on binaries (and others)" [High,Triaged] https://launchpad.net/bugs/436325 [02:42] ah, thanks for the info [02:42] Meths: I suspect we'll have to wait for the fix :-( [02:44] @ diones: at what part are you stuck? What guide are you following? [02:44] Yep, I assume the comments and approvals are unaffected so people could look through the commits instead and it could still get merged. [02:45] KIAaze: ah nevermind found the solution [02:45] ok :) [02:45] thanks btw [03:26] GASP lessons isnt loading for me [03:51] from https://help.launchpad.net/Translations/LicensingFAQ: [03:52] Can I select a packaged translation from some other template? Yes, however, it is up to you to check licensing compatibility. For example, you should not reuse nontrivial translations from a GPL module in a BSD-licensed project without asking the author for permission. [03:52] Why not, aren't translations of the GPL project under BSD? [03:53] why would they be? [03:53] because the translation is used in LP [03:54] sorry, LP is used for thanslation [03:54] as the FAQ stands, if you use LP for translating, that part of your code (the *.po and *.pot) are licensed under BSD [03:54] that FAQ talks about projects that are GPL, not *GPL and using LP for their translations* [03:55] it's confusing, am I missing something on that FAQ? [03:56] RenatoSilva: its under the heading 'Can I select a packaged translation from some other template?' [03:56] that means 'from outside launchpad' [03:56] this is a pretty clearer: https://help.launchpad.net/TermsofUse [03:57] I'm sorry I'm confused [03:58] can you explain your confusion [03:59] my software is GLP, and so it is its translation, dot. BSD? What? [04:00] *If* you use launchpad for translations, you are making an exception to your GPL to allow your translations to be BSD [04:00] as the terms of use say. [04:01] it's not there, can't find it [04:02] https://help.launchpad.net/Translations/LicensingFAQ "require that translations submitted in Launchpad licensed using the BSD licence. " [04:02] As far as I can understand, the work done inside LP will be BSD, right? But these translations made in LP that are BSD will --come back to the code-- (through branch export + merge) and therefore will become GPL anyway. This is my confusion [04:03] (00:02:21) lifeless: https://help.launchpad.net/Translations/LicensingFAQ "require that translations submitted in Launchpad licensed using the BSD licence. " ---> this quote is not on the FAQ either [04:04] RenatoSilva: they will still be BSD; but you can combine BSD work into GPL work [04:04] RenatoSilva: its on the top of the FAQ [04:05] lifeless: without any change to the licensing terms of the software [04:05] ? [04:05] thats right; if I create something that is BSD, and you create something that is GPL, you can incorporate my thing [04:06] you can't change my thing to be GPL; but you can incorporate it [04:06] weird! [04:06] copyright is weird [04:06] its a totally articial construction; open source software is a hack on top of this. [04:07] you can't change my thing to be GPL; but you can incorporate it ---> but that's what I do when I incorporate BSD stuff don't? How would one distinguish between BSD and GPL stuff when I don't give any notice about it? I just say the whole software is GPL? [04:08] it would be nice to say that the translations are BSD [04:08] it would be nice??? :D [04:08] in a strict sense its not needed, because the GPL includes all the requirements of the BSD [04:09] but GPL restricts BSD and therefore BSD translations [04:11] if you translate 1000 strings, they are BSD in LP, but when you import these 1000 items into the project code, which is GPL, then these 1000 translations become GPL and become restricted and cannot be used as BSD anymore. [04:11] no [04:12] they don't change, they are still BSD; but you can include them because BSD is compatible with GPL [04:12] If "import inot the code" means auto export to a output branch, then merge it with the trunk that is the input branch, then that means that what was BSD before now is GPL even inside LP [04:12] if you aren't permitting LP to use the pot as BSD then you can't use launchpad translations [04:13] tahts what the FAQ and terms of use say [04:14] lifeless: when I include them and the user downloads the software, he'll see only the GPL note. He won't know that there is BSD stuff there. And he could accuse me of doing that with evil intentions. [04:15] 13:07 < lifeless> it would be nice to say that the translations are BSD [04:15] 13:07 < lifeless> in a strict sense its not needed, because the GPL includes all the [04:15] requirements of the BSD [04:15] so it seems to me that it's not a matter of being nice, but that you should change the license of your software to GLP + BSD [04:15] lifeless: I'm sorry if I'm unclear [04:16] I'm not sure if you are asking me if you should do that, seeking legal advice, or something else [04:16] I'm not a lawyer: I can't give legal advice. [04:23] lifeless: if you omit the BSD note, you're hiding this info from the public. People don't know by just looking at your source code offline (outside of LP), that there is BSD stuff mixed together. I think people could say this is evil, because you're restricting the BSD stuff to GPL. For example, Imagine you don't even know LP exists, but you get the sofwtare.zip and extracts the source code. You want to create a proprietary app an [04:24] RenatoSilva: you're allowed to take BSD and use it completely privately: Microsoft do this with BSD code, and so do Apple. [04:24] RenatoSilva: your comment cut off at "proprietary app an" [04:24] You want to create a proprietary app and use the translations made in that source code. But you say "oh this software is GPL, can't use the translations", then other says: "No, part or all translations are BSD becasue they were made in LP", then you say "why didn't the programmer tell me this?". [04:25] but how to identify which msgids/strs are BSD and which are not (those imported into LP but never changed there)? [04:26] you just can't identify! thus in pratice the tranlsations are all GPL [04:28] I was thinking that I *should* made the software GPL + BSD, but it seems you mean that no one will care about this restriction [04:28] I think I've got it now [04:31] I just disagree (or don't understand) that BSD stuff is still BSD even after you imported LP results into the code. I think they --become-- GPL in that source, because BSD allows it [04:32] RenatoSilva: That are still BSD, it just isn't very practical to pick those bits out. [04:33] ScottK: but as I said in the example how would one be aware of that? [04:34] RIght, so in many cases it's a distinction without a difference. [04:34] ScottK: if you say all the content is GPL but in fact it's not (it's part GPL, part BSD) then you're lying about your sotware license [04:35] Not at all. I'm saying it's distributable under the GPL and that's true. It may also be distributable under other terms. [04:38] ScottK: but I should specify all the other terms. If I don't specify, then it's strictly GPL [04:40] There's no requirement to list all the options. [04:40] ScottK: otherwise you could get the translation part that you know it is BSD because "a LP friend told you that" and insert it into your proprietary app. However in the download package you don't mention BSD, so what's your argument for copying the work as it was BSD when your downloaded package doesn't stand that? Would you just say "because someone told me it is"? [04:40] Many people license software dual licensed commercial for paying customers and GPL for FOSS. [04:41] You'd need more than that. [04:41] You can't copy [04:41] Outside of GPL terms [04:42] Unless you get it from somewhere else that gives you BSD terms. [04:42] because the package doesn't mention other terms, it restricts you tor gpl [04:42] If that's all you have, yes. [04:42] BSD people get torked about this all the time with Linux kernel people borrow BSD code and modify it unders GPL and they can't take it back. [04:43] Not particualrly friendly, but there's no legal obstacle. [04:48] yes, you can't turn GPL into BSD, that's my point. When you import LP tanslations into GPL-only code, I do think you're restricting the work to GPL. The work is BSD in LP but not in the source code (trunk, download packages etc). You can reuse translations from LP under BSD, but you can't reuse the --same-- translations from the source code whcih is GPL-only. The same translations are GPL in one place (because BSD can be GPL'd), a [04:49] And the big problem is that when you import back your translations to LP, you're trying to change GPL into BSD which is illegal, that's what's so weird to get :) [04:49] I'm sorry guys if I'm annoying :( I just wanted to understand it :( [04:52] so it seems to me that anything containing those *.po(t) files --should-- declare they're BSD [04:53] which woiuld include any download package, project properites, license notes inside teh code etc [04:55] "All translations imported from sources external to Launchpad are owned by the translator that created them. In general, these translations are licensed under the same terms as the software for which they are a translation." [04:56] I think you should file a bug about that [05:02] for example GPL. When you download a po, not all the strings were necessarily translated at Launchpad. As the quote notes, part of this po or the whole po may be work done externally and imported into LP, therefore you're downloading a po that is partially or totally GPL, as it was totally BSD. The solution would be dowloading a partial po that was not imported but made in LP, therefore fully BSD. But this would require to know th [05:04] I think an easier solution would be just to share translations among projects with the same license. So the translations could be anything you like, but you'd only get suggestions from translations under the same license [05:04] if you want to use GPL translations, then you'll get suggestions from GPL projects, and so forth [05:05] RenatoSilva: without wanting to bog down in an argument. The copyright owner CAN turn GPL into BSD. That's possibly the key factor you're missing. [05:15] spm: I think the major problem I see is when you translate strings in LP that are therefore BSD, and you export it to a bzr i18n-out branch,and you merge it into trunk. It's not clear what is the license of the content of branches though. As my project is GPL, one could say that so they are the branches. So trunk contains BSD work converted into GPL. But usually trunk is the input for rosetta. [05:15] spm: After merging (or further changes, not sure), rosetta will import the work that was originally done on it. But theorically you could not import that work and make it BSD becasue it was GPL'd by rosetta export. Or one could stand that branch licenses are the ones from the project, except for all po(t) files that are BSD. Well, I don't know. [05:18] RenatoSilva: I am failing to see your problem. One of my GPL'd projects includes a source code function straight from OpenBSD. ie I deliberately distribute the openbsd .c & .h files with my project. Where's the beef? Translations are no different. Just blobs of creativity/activity. [05:19] spm: (about the copytright) the onwer can change licenses, but it shoud do it. My download package does not mention BSD, therefore you can't reuse translations --from that package--, because I didn't published that package as GPL + BSD. [05:21] then you have a bug in how your package is explained. I have a section that describes every bit of the package and what licenses they follow. You should do the same. Problem goes away and becomes a non-issue. [05:21] spm: your project notes all the licenses though, right? I mean, the openbsd files are not inheriting GPL because of the lack of a note like "these files here are in another license XYZ" [05:22] RenatoSilva: isn't that what spm just said? [05:23] yes, but I was writing it before he answered :) [05:23] Ah. [05:37] "If and when we allow proprietary projects to use Launchpad for translation, they will get the same translation suggestions as anyone else. Those may include translations you entered (and conversely, those projects' translations may be included in the suggestions you receive as well)." [05:38] I think this suggests that the --whole-- po(t) files become BSD when imported into LP, even if it's GPL or proprietary! [05:38] Copyright isn't intrinsically a per-file concept. [05:39] and that branch licenses may not be just the one declared in project properties [05:40] well it may, as long as it's the copyright onwer who's importing GPL/proprietary pos into LP [05:41] the copyright ower does not convert from GPL to BSD in my example, it gives the pos to LP under another license terms :) [05:43] RenatoSilva: I guess we've failed to answer your questions to your satisfaction. Can you summarise your key issues and lodge them as a Question against LP Translations? They've been thru this stuff with a fine tooth comb and I have the fullest confidence they'll be able to answer your concerns satisfactoryly. [05:43] "convert from GPL to BSD" isn't something that can happen. A copyright owner may choose to distribute a work with different licensing terms than they have distributed it in the past. Some licences allow non-copyright holders to redistribute a work with different terms to the ones granted by the license they received it under. [05:43] so when rosetta does an auto import, it's getting the pos under BSD terms, whatever the original licence was (the one submitting the pos are supposed to have the power of changing licenses -- the copyright owners) [05:44] I'm not a lawyer etc, but precision in language seems pretty important to have a useful conversation about this stuff. [05:45] spm's suggestion is a good one. [05:45] spiv: yes that's what I mean, there's no GPL -> BSD, it's the owner changing the license :) (as spm said I was missing this point) [05:47] spm: I'm sorry! I was just dumping my conclusions, sorry [05:49] np [05:51] spm: I'm sorry but maybe the LP docs need to be clarified. As I said, you change the license to BSD, but when you read other parts of docs you think that's not how it works (e.g. "All translations imported from sources external to Launchpad are owned by the translator that created them. In general, these translations are licensed under the same terms as the software for which they are a translation." --> this made me think that th [05:51] but ok this ^ was my last msg, won't annoy you anymore.... thanks so much! [05:53] thank you, good night [05:54] Good night. [06:58] Good morning [09:57] good morning [09:58] Apport retrace service classified one of my bugs as duplicated and linked to an original bug which I don't have access to [09:58] how do I remove the duplicate status ? [09:59] joaopinto: click on the Mark as duplicate and remove the bug number. [09:59] ok, tks [09:59] (it's an optional field). [09:59] np [10:00] hum, Mark as duplicate is not available [10:00] joaopinto: sorry, what's the bug? [10:01] ops, its the "Duplicate of" field, done it [10:01] Great. [10:02] joaopinto: Why would you remove the duplicate marker just because of that? [10:02] apport is generally right. [10:02] wgrant, because 1) I can't confirm that is a duplicate 2) I am unable to follow up the bug handling, which is the entire purpose of reporting a bug [10:03] joaopinto: With apport it's different. Trust apport. It is usually right. The original should be publicised eventually. [10:03] Plus if it's a duplicate, you are not necessarily required. [10:04] wgrant, Is not the bug that needs me, I am the one needing the bug fixed [10:05] apport maybe right, that does not help me :) [10:05] A triager will make the bug public eventually. [10:05] You're just making everything harder by unmarking it. [10:07] wgrant, it's a serious bug, i can't login into msn using empathy, your statements use the "will make", "is usually", that is all very uncertain to me, are you in contact with the person that will triage the bug, or that just a guess ? [10:09] from my perspective, I have a bug, I have reported, I was informed that it maybe already been report, but I have no information if the initial report is beeing worked or not [10:12] if the initial bug report gets public I will handle my own record and set it as duplicate === jtv is now known as jtv-afk === jtv-afk is now known as jtv === Pici` is now known as Pici === matsubara-afk is now known as matsubara === sayakb_ is now known as sayakb === sayakb_ is now known as sayakb [14:54] Hey eveyone, launchpad doesn't appear to be taking my strings from bzr? [14:54] can anyone help me figure out why [14:56] lamalex, what do you mean taking your strings? === sayakb_ is now known as sayakb [14:59] beuno: it's not importing my translations [15:00] i have it set to do a bzr import [15:01] what does it look for when doing the import? [15:04] Ah, does the .pot need to be in bzr? === andreas__ is now known as ahasenack [15:08] beuno: ? [15:09] lamalex, I don't know much about translations, but henninge, jtv, danilos and dpm do [15:09] lamalex: do you have a url for the release series in question? [15:10] lamalex: and yes, you do need a template otherwise not much importing is going to happen. :) [15:20] jtv: ah, mine is autogenerated. I don't know why I'd assume that lp would autogenit for me.. [15:20] lamalex: we're hoping to support that at some point, but even then it's going to be "most common cases" only. [15:21] gotcha [15:21] ok, so I pushed my .pot to bzr. How long should it take to import? [15:22] jtv, danilos, jml, at some point we need to figure out how to make this whole thing easier [15:22] everyone gets lost in translations [15:23] lamalex: hopefully within the hour [15:24] beuno: it seems like a lot of magic [15:24] beuno, heh, yes [15:24] lamalex, it is, and we need people to know how it works ;) [15:24] magicians are so 18th century [15:25] jml, I fell in love with your headphones === Ursinha changed the topic of #launchpad to: Code hosting offline 10.00-10.30 UTC 1st Oct -- http://is.gd/3MyHY | Read https://help.launchpad.net for help | Help contact: Ursinha | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: see channel #launchpad-dev [15:58] Hey I know I live under a rock, but are bug reports no longer possible via the web interface? because when clicking on the "report a bug" (https://bugs.launchpad.net/ubuntu/+source/zlib/+filebug) you get redirected to https://help.ubuntu.com/community/ReportingBugs is this normal now? [16:02] VK7HSE: apparently. there is widespread gnashing of teeth [16:02] You can append ?no-redirect to the url [16:02] VK7HSE, what maxb said :) [16:02] Ahh! not an issue just got me a tad confused when I was going in circles! ;) === ahasenack is now known as ahasenack-lunch [16:21] I can't edit the description of https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/421318, I get ""Entity-body was not a well-formed JSON document." [16:21] Launchpad bug 421318 in totem "totem crashed with SIGABRT in __kernel_vsyscall()" [High,Triaged] [16:25] liw, this is bug 423924 [16:25] Launchpad bug 423924 in malone "Entity-body was not a well-formed JSON document when updating bug description" [High,Triaged] https://launchpad.net/bugs/423924 [16:25] liw, happened to me, and insisting made it go away :/ [16:26] good, then it's known, thanks [16:32] https://edge.launchpad.net/ubuntu click 'Report a bug" takes me to https://help.ubuntu.com/community/ReportingBugs "you can file one via Launchpad." which takes me back to https://edge.launchpad.net/ubuntu [16:32] I turned off edge, same thing [16:33] CarlFK: doesn't that help page give a different URL to use? [16:33] hggdh in #u-bugs is not having this problem [16:33] https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net [16:33] idnar: yes [16:34] hmm, okay, then I don't know [16:34] if I visit http://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect then I don't get redirected [16:34] it is doing a redirect or something... trying to figure out if FF will show me those [16:34] I can confirm that I get sent to +filebug on Edge. [16:35] CarlFK, you can append ?no-redirect to the url [16:35] http://bugs.launchpad.net/ubuntu/+source/linux/+filebug?no-redirect [16:36] that;s jsut for me... stand by... [16:36] this is looking good [16:36] CarlFK, yes, the ubuntu process to file a bug changed, so you have to append the no-redirect for it to go to lp [16:36] it's explained in the page you are redirected to :) [16:42] Ursinha: I did not have the no-redirect... [16:44] hggdh, what do you mean? [16:44] when I was checking CarlFK statement, I clicked on "report a bug", and got sent directly to +filebug [16:45] this was on edge [16:46] still happening :-) [16:47] Ursinha: ^^ [16:48] hggdh, in this case I'll have to check [16:49] perhaps membership in some group makes a difference? Or cache? [16:49] hggdh: Ubuntu bug squad (or whatever it's called now) doesn't get the redirect. [16:50] The assumption is you'll know if you should use the web U/I or ubuntu-bug [16:50] ScottK: ah, there it is. Thank you. [16:51] thanks ScottK [16:51] You're welcome [16:52] hggdh: Ursinha - thanks. was making me dizzy === ahasenack-lunch is now known as ahasenack === soeb_ is now known as soeb === matsubara is now known as matsubara-lunch === EdwinGrubbs is now known as Edwin-lunch [18:24] Is it intentional that there's no obvious way, on the milestone page, to tell if the milestone is active or not? === mrooney|w1 is now known as mrooney|w [18:54] i cannot updates bug reports at the moment [18:55] is it possible that there is a bug in the new functionality [19:03] mahfouz, I think you hit bug 423924 [19:03] Launchpad bug 423924 in malone "Entity-body was not a well-formed JSON document when updating bug description" [High,Triaged] https://launchpad.net/bugs/423924 [19:04] is that what's happening to you? [19:04] yes, it's like in the png posted [19:05] thanks for pointing me [19:05] I will mark as affected === yofel_ is now known as yofel [19:07] thanks for letting usknow mahfouz [19:07] *us know [19:09] hello === matsubara-lunch is now known as matsubara [19:10] I would like to "unsuscribe" from Launchpad, how can I do thatN [19:10] ? [19:11] jeromeg, if you're not using your account anymore, at the bottom of your profile page you have the "Deactivate your account" link [19:12] mmm, can't find it here [19:19] https://answers.launchpad.net/launchpad/+faq/47 [19:19] ok, got it [19:19] thank you === jon is now known as Guest77383 === Edwin-lunch is now known as EdwinGrubbs [20:32] I'm hosting a project with and I performed my initial bzr push to launchpad a few days ago and noticed this morning that there is a section of a file that needs to be removd [20:32] how can I go about getting rid of an old commit from the history of the code? [20:32] *with launchpad [20:37] slayton, well, I guess removing the branch would do what you want [20:38] rockstar, ^ [20:38] slayton, well, you'll probably want to delete the branch from launchpad first. [20:38] slayton, I'm assuming it's a file that has a password or something confidential in it? [20:40] something like that [20:40] how do I delete a branch from launchpad [21:05] slayton, when you're in the branch, there's the "Delete branch" option in the right portlet [21:05] in the branch page in Launchpad, I mean [21:10] ok thanks === sayakb_ is now known as sayakb === cprov is now known as cprov-afk === matsubara is now known as matsubara-afk === sale_ is now known as sale === Ursinha is now known as Ursinha-afk [23:05] sinzui: Before I file a bug, is this expected behaviour: I'm a driver in the landscape-project project group, and landscape and landscape-client projects, by way of being a member of the landscape team. [23:06] sinzui: If I navigate an open milestone via the project group I have no means to edit it (to close it in this case). [23:06] hmm [23:06] sinzui: But if I get to the same milestone via one of the projects I'm able to do so. [23:06] sinzui: It's not too big a deal for me right now, given that I can easily change my navigation behaviour, but one place it causes problems is in launchpadlib-based scripts. [23:07] projectgroup milestones are virtual [23:07] jkakar: They are created for the view based on the name string and the product it is pared with. They are only usable for presenting reports [23:07] sinzui: The script we use to mark all bugs as 'Fix Released' and close a milestone operates on the project group, not individual projects. All of a sudden, after the recent rollout we're getting a 500 error when the scripts tried to deactivate the milestone. [23:08] jkakar: I can send you the script I use to do that [23:08] sinzui: I *think* this behaviour worked before the rollout, but I could be mistaken, I know there's been some changes to our script recently. [23:08] * sinzui looks [23:08] jkakar: projectgroup milestones have never been in the database [23:08] sinzui: That would be appreciated, thanks. [23:09] sinzui: Okay. So, do you think this is a bug? It *feels* like a bug from a user experience point of view, but I can understand if the model doesn't necessarily explicitly provide project group milestones. [23:09] no it is by design. [23:09] sinzui: Okay, then I'll file a bug. :) [23:09] jkakar: consider this... [23:10] the milestone names are a set create from all sub projects. we do not know if those milestones *are* the same. we are guessing. [23:10] sinzui: Ah, I see. [23:10] sinzui: So, I guess there's no way to "create a milestone" for a project group, either? [23:12] jkakar: This nasty approach is also what prevents two series in a project to have the same milestone name. We are forcing projects to have unique milestones to improve our chances of guessing. [23:12] sinzui: Okay, well I guess I won't file a bug, but will just mention that this is surprising and a bit suboptimal as far as user experience goes. [23:12] jkakar: We all want that feature. It would be like carpetbombing all projects by creating series and milestones to accomplish its goal. [23:13] sinzui: I think adding a comment on the project group view of a milestone that says "Edit this milestone for _project A_, _project B_ and _project C_" could help, with _project A_, etc. being links to the edit page. [23:13] jkakar: We want to do, but we need to do it gracefully. [23:13] jkakar: indeed that is a bug and one that we can fix this release. [23:13] sinzui: Yeah, makes sense. I'd rather live without it a bit longer while waiting for the graceful solution than doing something hasty that will make things more confusing. :) [23:14] sinzui: Thanks for explaining the rationale behind the behaviour.