RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office)
ActivePublic

Hosted by daniel on Apr 20 2016, 9:30 PM - 10:30 PM.

Description

See the Architecture meetings page for more general information about this meeting (also: Phab query: list of upcoming RFC meetings, Phab query: list of all RFC meetings).

Recurring Event

Event Series
This event is an instance of E66: ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office), and repeats every week.
RobLa-WMF mentioned this in Unknown Object (Event).Apr 13 2016, 6:54 PM
RobLa-WMF renamed this event from RFC Meeting: <topic TBD> (<see "Starts" field>, #wikimedia-office) to RFC Meeting: <topic TBD> (2016-04-20, #wikimedia-office).Apr 13 2016, 7:12 PM
RobLa-WMF updated the event description. (Show Details)
RobLa-WMF renamed this event from RFC Meeting: <topic TBD> (2016-04-20, #wikimedia-office) to RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office).Apr 13 2016, 9:51 PM
RobLa-WMF updated the event description. (Show Details)

Any chance we could start 30 minutes later? I'm going to be in class until 21:20 UTC, and then need another 5-10 minutes to find a place to sit down, etc.

I think this is reasonable as long as we can decide quickly. Any objections? (particularly TechCom members)

brion added a subscriber: brion.Apr 13 2016, 11:22 PM

That'd be fine for me, as long as I don't lose network again. :)

Agh actually I'll be at the airport boarding a plane towards Germany around then. So... Depending on connectivity. :)

@Legoktm - one possibility is for us to postpone talking about T91162 for another week. Is the regular RFC meeting time always bad for you, or just next week?

Is the regular RFC meeting time always bad for you, or just next week?

It's bad for me until the end of June :(

RobLa-WMF changed the start date for this event from Apr 20 2016, 9:00 PM to Apr 20 2016, 9:30 PM.Apr 14 2016, 4:02 AM
RobLa-WMF changed the end date for this event from Apr 20 2016, 10:00 PM to Apr 20 2016, 10:30 PM.

It's bad for me until the end of June :(

Ok....well, how about we should for 30 minutes later than normal (barring objections in the next 24 hours). Let's make a decision on this so that we can announce the revised time in the weekly Tech News.

RobLa-WMF updated the event description. (Show Details)Apr 14 2016, 4:11 AM

3:30 PM <wm-labs-meetbot> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.html
3:30 PM <wm-labs-meetbot> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.txt
3:30 PM <wm-labs-meetbot> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.wiki
3:30 PM <wm-labs-meetbot> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.log.html

#wikimedia-office: T91162 - Shadow namespaces

Meeting started by robla at 21:31:17 UTC. The full logs are available
at
https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.log.html
.

Meeting summary

  • Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (robla, 21:31:54)
    • LINK: https://phabricator.wikimedia.org/T91162 (robla, 21:33:29)
    • question being discussed: should legoktm begin work on implementing phase 1? (robla, 21:49:24)
    • legoktm is hoping for approval on the first steps section, and then discussion of some of the questions in open questions (robla, 21:51:12)
    • some questions on how to handle CSS that comes with the remote page; GlobalUserPage has some handling for this but not perfect (bd808, 21:57:04)
    • TimStarling sais that $wgEnableScaryTranscluding already allows remote as well as local parsing of remote templates (DanielK_WMDE, 21:58:07)
    • LINK: https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules (legoktm, 21:58:15)
    • LINK: https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules (bd808, 21:58:45)
    • AGREED: <TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page (robla, 22:01:35)
    • question discussed: how we could allow local wikis to append/augment remote content, specifically in the use case of help pages: https://www.mediawiki.org/wiki/Topic:T2f1remrtx6et2ba (robla, 22:04:22)
    • Tim suggested replacing the current GUP opt-out sytem with a double underscore tag that sets a page property and can be queried for (legoktm, 22:04:52)
    • <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms" (robla, 22:13:55)
    • Use case of "Centralized, but locally-appendable, documentation pages" is out of scope (bd808, 22:14:43)
    • IDEA: <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]? (robla, 22:21:40)
    • IDEA: attribution of the foreign source seems reasonable and necessary (bd808, 22:26:18)
    • TimStarling and subbu favor an explicate foreign template namespace (bd808, 22:26:50)

Meeting ended at 22:30:29 UTC.

People present (lines said)

  • legoktm (41)
  • bd808 (30)
  • James_F (30)
  • DanielK_WMDE (26)
  • robla (25)
  • subbu (20)
  • SMalyshev (20)
  • TimStarling (19)
  • cscott (6)
  • quiddity (5)
  • wm-labs-meetbot (3)
  • duploktm (3)
  • stashbot (2)
  • Scott__WUaS (1)
  • mobrovac (1)

Full transcript:

121:31:17 <robla> #startmeeting T91162 - Shadow namespaces
221:31:17 <wm-labs-meetbot> Meeting started Wed Apr 20 21:31:17 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot.
321:31:17 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
421:31:17 <wm-labs-meetbot> The meeting name has been set to 't91162___shadow_namespaces'
521:31:17 <stashbot> T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162
621:31:54 <robla> #topic Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/
721:32:15 <robla> hi folks!
821:32:38 <legoktm> hello
921:32:54 <legoktm> I think everyone here is familiar with the shadow namespaces concept, right?
1021:33:05 <robla> task: T91162
1121:33:05 <stashbot> T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162
1221:33:29 <robla> #link https://phabricator.wikimedia.org/T91162
1321:33:57 <legoktm> I wrote up a "first steps" section at https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#First_steps
1421:35:09 <legoktm> And wanted to make sure that sounded reasonable
1521:35:36 <legoktm> I'm going to start implementing all of that...now basically.
1621:35:59 <robla> legoktm: what do you think would be reasonable to get out of this meeting? is it approval time for this, or are we still earlier in the process?
1721:36:06 <subbu> i had a question. why remote action=parse vs. remote action=expandtemplates? i.e. don't titles need to resolved wrt the local wiki?
1821:36:32 <subbu> i meant: links to resources besides the remote resource being accessed
1921:37:04 <DanielK_WMDE> yea, good point. where to links point to?
2021:37:04 * robla regrets not filling in the "meeting type" field in https://phabricator.wikimedia.org/E162
2121:37:17 <legoktm> robla: approval for the first steps section, and then discussion of some of the questions in open questions
2221:38:11 <SMalyshev> so I understand this would be including rendered HTML from other wikis? what are the security implications?
2321:38:14 <legoktm> subbu: I think the links should point to content on the remote wiki, because that's how the content was authored on that wiki. it's currently what we do for foreignfilerepo, and what we should be doing for globaluserpages except there's a bug in that
2421:38:26 <Scott__WUaS> Hi
2521:39:02 <subbu> how does this work for templates? ex: {{remote-tpl|link=[[my_local_article]]}}?
2621:39:26 <James_F> legoktm: [Low priority] I'm curious as to your thoughts on whether this approach will also eventually apply to the i18n system (i.e. the magic of the MediaWiki: namespace).
2721:39:27 <legoktm> SMalyshev: basically what's outlined at <https://www.mediawiki.org/wiki/Extension:GlobalUserPage#Caveats>, the remote wiki can't allow raw HTML or anything. The HTML emited by the parser is assumed to be safe to output
2821:40:11 <legoktm> subbu: everything would be parsed in the context of the remote wiki, and links would point to the remote wiki
2921:40:32 <subbu> hmm ... need to ponder that.
3021:40:59 <SMalyshev> legoktm: so templates are resolved with respect to remote wiki?
3121:41:01 <legoktm> James_F: you mean something like https://www.mediawiki.org/wiki/Extension:MessageCommons ?
3221:41:22 <bd808> phase one is pretty much making it possible to do what GlobalUserPage does on any page. Is that a reasonable summary?
3321:41:32 <James_F> legoktm: Yeah, ish.
3421:41:39 <SMalyshev> that may limit template usage that use context (stupid example: Welcome to {{this page}}, {{user}})
3521:41:40 <legoktm> bd808: GlobalUserPage and ForeignFileRepo*, but yes
3621:41:54 <James_F> legoktm: Plus also all the complications about edit vs. create vs. "over-ride".
3721:42:00 <DanielK_WMDE> subbu: it would be extremely hard to make it work correctly otherwise, i think.
3821:42:53 <cscott> James_F, legoktm: [Low priority] I'm curious about using this approach for the Module namespace.
3921:42:54 <subbu> wouldn't action=expandtemplates done remotely handle {{remote-tpl|link=[[my_local_article]]}} and such?
4021:42:54 <legoktm> the applications this would be used for would be global user pages, foreign files, and help pages (https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#Applications)
4121:43:34 <legoktm> subbu: kind of, but what if the template does a {{#ifexist:}} on "my_local_article"?
4221:43:45 <mobrovac> subbu: but then you have the same problem in that your local article is remote for the remote wiki, don't you?
4321:43:54 <subbu> right ...
4421:44:00 <legoktm> cscott: modules and templates need local parsing, which would be phase 2
4521:44:00 <DanielK_WMDE> legoktm: global templates? lua modules?
4621:44:07 <legoktm> DanielK_WMDE: phase 2!
4721:44:08 <James_F> From a product POV, my main concern is about how we make calling remote templates (and modules) "work" nicely in multi-lingual contexts (or to be more blunt, how do we avoid English imperialism and making non-English speakers not feel excluded/second class/etc.).
4821:44:13 <DanielK_WMDE> legoktm: :D
4921:45:22 <legoktm> Er, before we start talking about global templates/modules, can we make a decision on phase 1/"First steps"?
5021:45:22 <DanielK_WMDE> legoktm: with MediaWikiServices in place, we can start thinking about refactoring Parser, so it doesn't rely on global state. But I guess before we can safely parse a page "for" another wiki in the same request, pretty much all of MediaWiki will need to be refactores to not use global state
5121:45:37 <TimStarling> I have no objections to the first steps
5221:45:41 <James_F> legoktm: Yeah, sorry.
5321:45:52 <James_F> I'm in favour of Phase 1 too.
5421:45:53 <legoktm> DanielK_WMDE: Yes. Which is why right now everything is just making cross-wiki API requests
5521:46:38 <bd808> doing things is phases is good because it limits the "what about..." questions and should lead to something that is usefully shippable.
5621:46:39 <subbu> sorry .. i read the rfc in detail for the first time today and so i am having all these basic questions.
5721:47:14 <DanielK_WMDE> legoktm: should be fine for now. not for system messages though (thinking about James_F's question)
5821:47:24 <robla> what question are we trying to answer here? sounds like "what scope should an included resource have?", but I'm not sure that captures it
5921:48:00 <DanielK_WMDE> legoktm: how about programmatic access to the page source? will that be possible in a transparent way, via a WikiPage or Revision object?
6021:48:03 <DanielK_WMDE> or is it all just show?
6121:48:46 * DanielK_WMDE stops asking questions and goes to check the wiki page
6221:48:50 <legoktm> robla: "should legoktm begin work on implementing phase 1?" is the question I'm hoping to get answered :)
6321:49:00 <bd808> yes
6421:49:19 <TimStarling> regarding first step subitem "Start abstracting ForeignFileRepo remote-transcluding code into core to handle other namespaces"
6521:49:24 <robla> #info question being discussed: should legoktm begin work on implementing phase 1?
6621:49:28 <James_F> DanielK_WMDE: Let's not encourage new code assuming a 1:1 relationship between view and edit modes. :-)
6721:50:05 <TimStarling> a subtask of that, not mentioned yet, is the fact that CSS comes with the remote description page
6821:50:31 <TimStarling> abstractly, we are transcluding a bundle of content plus CSS
6921:50:46 <legoktm> DanielK_WMDE: by "page source" do you mean wikitext? Since remote parsing doesn't really have a concept of source, I don't think there would be. Things like Title::isKnown() would return true though
7021:51:12 <robla> #info legoktm is hoping for approval on the first steps section, and then discussion of some of the questions in open questions
7121:51:19 <DanielK_WMDE> legoktm: whetever content there is. wikitext for global templates. loa code for global modules
7221:51:23 <DanielK_WMDE> *lua
7321:51:59 <DanielK_WMDE> well, for global templates, we could also go for html based transclusion. that ties in with last week's rfc
7421:52:01 <subbu> i guess my other question is whether foreign-file-repo, global-user-page, remote-templates are all instances of the same problem ... i.e. full parse of content in remote wikis.
7521:52:35 <DanielK_WMDE> subbu: the way templates work right now, they can't be rendered on the remote system if you want to include them locally
7621:52:37 <legoktm> TimStarling: right. And that CSS is loaded outside of ResourceLoader, which is non-ideal. Also RL modules added by parser tags/functions aren't emitted in action=render. GlobalUserPage has some handling of it via action=parse, but that isn't perfect.
7721:52:56 <subbu> DanielK_WMDE, right.
7821:53:38 <subbu> i am mostly trying to wrap my head around remote-parse of transclusions ...
7921:53:52 <James_F> Remote parse of local-to-remote transclusions.
8021:54:06 <legoktm> subbu: remote templates (and modules) are a different class of problem, which I think require local parsing. But foreign file repo, global user page, and help pages are all okay with remote parsing
8121:54:08 <TimStarling> templates obviously can be rendered remotely, that is the existing feature $wgEnableScaryTranscluding
8221:55:16 <TimStarling> $wgEnableScaryTranscluding also allows local rendering with the RAW option
8321:55:24 <subbu> okay .. so, that fits into how i understood this then. i am happy to ask basic qns. later if you guys want to move along. :)
8421:56:08 <TimStarling> the one thing we *don't* have is mixed local/remote rendering, e.g. templates coming from one wiki and links from another
8521:56:22 <subbu> right.
8621:56:31 <TimStarling> but the current proposal is just to refactor the things that do exist
8721:56:37 <subbu> got it. thanks.
8821:57:04 <bd808> #info some questions on how to handle CSS that comes with the remote page; GlobalUserPage has some handling for this but not perfect
8921:57:14 <James_F> Do we have any live questions about the main question? It feels like we have agreement?
9021:58:03 <TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page
9121:58:07 <DanielK_WMDE> #info TimStarling sais that $wgEnableScaryTranscluding already allows remote as well as local parsing of remote templates
9221:58:15 <legoktm> https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules
9321:58:45 <bd808> #link https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules
9421:59:16 <legoktm> ok, the first open question I wanted to discuss is actually the last one on https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#Open_questions
9521:59:26 <legoktm> specifically regarding the opt-out feature GlobalUserPage currently has
9621:59:37 * DanielK_WMDE wonders whether Content objects need to know their "home", to provide context to local rendering, and allow rendering against the correct remote
9721:59:54 <legoktm> if your page is blank, or you wrap the entire thing in <noinclude> tags, then we pretend your user page doesn't exist
9822:00:08 <James_F> legoktm: Except for MW: where we use '-', magically.
9922:00:19 <legoktm> right
10022:00:20 <TimStarling> could have a double-underscore tag instead
10122:00:23 <James_F> It'd be nice to come up with a consistent system.
10222:00:35 <DanielK_WMDE> TimStarling: +1
10322:00:38 <James_F> __PLEASENOINHERIT__
10422:00:53 * robla plans to use the #agreed command on "<TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page"
10522:01:21 <DanielK_WMDE> James_F: __OHGODPLEASENOINHERIT__
10622:01:27 <legoktm> TimStarling: the double underscore would set a page prop that we could query for? I like that
10722:01:35 <James_F> +1
10822:01:35 <robla> #agreed <TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page
10922:01:40 <TimStarling> yes
11022:03:09 <DanielK_WMDE> how would that work for non-wikitext content?
11122:03:24 <legoktm> ok, another question that came up recently was how we could allow local wikis to append/augment remote content, specifically in the use case of help pages: https://www.mediawiki.org/wiki/Topic:T2f1remrtx6et2ba
11222:03:40 <DanielK_WMDE> do we need to define a magic word syntax for other formats?
11322:03:42 <James_F> Do we want to do that?
11422:04:13 <legoktm> DanielK_WMDE: the implementation would define a different way to set the page property in the ParserOutput object?
11522:04:22 <James_F> DanielK_WMDE: The __FOO__ system (and e.g. #REDIRECTs) needs replacing with other stuff for general content types anyway. Let's not divert this discussion?
11622:04:22 <robla> #info question discussed: how we could allow local wikis to append/augment remote content, specifically in the use case of help pages: https://www.mediawiki.org/wiki/Topic:T2f1remrtx6et2ba
11722:04:52 <legoktm> #info Tim suggested replacing the current GUP opt-out sytem with a double underscore tag that sets a page property and can be queried for
11822:05:53 <bd808> legoktm: quiddity
11922:05:57 <bd808> grr
12022:06:07 <bd808> quiddity's question is very complex
12122:06:18 <DanielK_WMDE> legoktm: yea, we need to come up with a mechanism for that i guess
12222:06:28 <bd808> it would be some sort of merge operation between remote and local content
12322:06:56 <bd808> and subject to all the problems of keeping a local patch against a remote source
12422:07:04 <TimStarling> needs a better user story or UI description I guess
12522:07:46 <quiddity> James_F, that at least, was the solution that occurred to me, regarding how to prevent constant forking/drift/redundancy/replication. How else do we get improvements to https://en.wikipedia.org/wiki/Help:Link into https://meta.wikimedia.org/wiki/Help:Link whilst still allowing Enwiki (etc etc etc) to keep their local page-hatnotes, and section-hatnotes, and section-addendums.
12622:07:47 <James_F> My strong recommendation would be to not even try to support that use case.
12722:08:30 <James_F> quiddity: "Don't".
12822:09:07 <quiddity> Nod. I just wanted to ensure it is considered, as much as feasible.
12922:09:08 <James_F> Going out of our way to make the system worse (slower, more broken, more complex) just so that users can avoid working with each other is not "better" for users
13022:10:03 <bd808> doing it "right" probably requires inventing a human-level AI
13122:10:16 <DanielK_WMDE> legoktm: regarding the low number of users that use opt-out on meta... when comparing feature usage numbers, i think it makes sense to scale the usage by the number of edits/actions the user did recently. across all projects, in this case.
13222:11:02 <DanielK_WMDE> some features are only used by a few power users, but may be important to, well, empower them to be power-users.
13322:11:06 <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms"
13422:11:15 <quiddity> That's... not quite the way I'd put it, James_F. I want *increase* the number of editors from the large wikis, who work on improving the main/default documentation, so that all languages can benefit.
13522:11:20 <cscott> i don't think we're helped by trying to make legoktm solve all the world's problems at once
13622:11:23 <James_F> cscott: Indeed. There's a use-case.
13722:11:40 <bd808> cscott: agreed
13822:11:41 <legoktm> DanielK_WMDE: right.
13922:12:02 * quiddity nods.
14022:12:06 <bd808> this is a common issue in RfC meetings I think. The "what about.." scope expansion
14122:12:10 <cscott> without getting too far on a soapbox, i'll note that git shows that we can maintain completely separate copies of en:Help:Link and :meta:Help:Link and still provide good tools for merging changes between them.
14222:12:18 <James_F> Yup.
14322:12:22 <cscott> we don't need to make them somehow be exactly the same entry in a database somewhere
14422:12:40 <TimStarling> next question?
14522:13:01 <bd808> Namespacing?
14622:13:04 <James_F> Does legoktm need anything else? Support/ideas/help from any of us?
14722:13:34 * cscott turns into a pumpkin
14822:13:41 <legoktm> Those are all the questions I had for phase 1 stuff, the remaining questions are about phase 2/local parsing stuff
14922:13:54 <legoktm> Yeah, namespacing. "Namespacing: should we have a "Global templates" namespace or should it be transparent like InstantCommons?"
15022:13:55 <robla> #info <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms"
15122:14:13 <James_F> legoktm: Transparent, I think.
15222:14:15 * robla probably should have used the #idea command
15322:14:30 <legoktm> James_F: Not at the moment, but I will definitely ask when I need it
15422:14:30 <DanielK_WMDE> legoktm: a separate namespace is basically an opt-in mechanism
15522:14:31 <subbu> I prefer explicit global namespace instead of implicit/transparent fallback which can have unintentional side-effects when, for example, a previous use of global template is shadowed by a newly created local template of the same name.
15622:14:35 <SMalyshev> legoktm: there probably needs to be a way to know where template comes from
15722:14:43 <bd808> #info Use case of "Centralized, but locally-appendable, documentation pages" is out of scope
15822:15:02 <SMalyshev> whether it is local or global
15922:15:07 <James_F> If we're going to have transparent fallbacks for "some" namespaces and not for others I think that's a worse, not better, outcome.
16022:15:10 <SMalyshev> but that can be done with transparent too
16122:15:14 <James_F> (Some == File, User, ???)
16222:15:21 <legoktm> SMalyshev: why does the user need to know where the template comes from?
16322:15:41 <James_F> So they can fix it, I guess?
16422:15:57 <subbu> James_F, legoktm but we resolved that global templates are not the same as GUP, remote-file-repos, etc?
16522:16:00 <bd808> the tabs solution would handle that right? Adding info on the imported page that points back tot he origin?
16622:16:12 <TimStarling> I agree with subbu
16722:16:16 <SMalyshev> legoktm: looking at GUO I see some things are still resolved in origin's context
16822:16:17 <quiddity> So that they don't check locally first, but instead go directly to the actual destination.
16922:17:05 <SMalyshev> legoktm: s/GUO/GUP/
17022:17:18 <legoktm> SMalyshev: uh, which things?
17122:17:33 <SMalyshev> legoktm: https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage#Where_content_comes_from <- these?
17222:17:36 <James_F> I'm not sure the "let's do lots of tabs" option is a great one for users – see e.g. https://www.mediawiki.org/wiki/File:Upload-classify.png with "Read" | "View on Commons" | "Add local description".
17322:18:06 <legoktm> SMalyshev: yeah, the "Wikilinks are relative, so they'll point to the local wiki" is a bug, https://phabricator.wikimedia.org/T89916
17422:18:26 <SMalyshev> legoktm: also, I'm not sure how permissions would work - what if you can edit local wiki but not central wiki?
17522:18:33 <DanielK_WMDE> uh... btw, how do section edit links work with global templates? those are injected in a magic way on the fly...
17622:19:16 <legoktm> SMalyshev: you can't edit the template then?
17722:19:22 <legoktm> DanielK_WMDE: I have no idea :P
17822:19:25 <bd808> I guess we forked here. The namespace question is about whether asking for [[Template:Foo]] gets you a template from a remote or if you have to say [[Global template:FOO]] ?
17922:19:38 * robla plans to use #endmeeting very close to 22:30 UTC
18022:19:42 <James_F> Yeah.
18122:19:43 <SMalyshev> legoktm: but you should be able to understand why. I.e. it should tell you "you can't edit it because it's on CentralWiki"
18222:20:23 <legoktm> SMalyshev: wouldn't a notice that says "This template is from CentralWiki blah blah blah" like the InstantCommons/GUP notice?
18322:20:24 <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]?
18422:20:33 <TimStarling> yes
18522:20:41 <bd808> works for me then
18622:20:43 <SMalyshev> legoktm: that's one way of knowing where the template comes from :)
18722:21:27 <TimStarling> that way when you edit [[Template:Foo]] and see that it is a redirect, you would know that it is used locally and be alerted to what editing it will do
18822:21:40 <robla> #idea <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]?
18922:21:47 <subbu> what TimStarling said
19022:22:10 <SMalyshev> legoktm: another thing - suppose, you have local Template:Foo and global Template:Foo. And you want to delete the local one. So you are attempting to delete it, but unknown to you, some other admin just deleted local one. So oyud instead delete a global one. Wouldn't you want to know which one it is really?
19122:22:35 <SMalyshev> or, alternatively, we won't allow both local and global have the same name?
19222:22:48 <bd808> I don't think you can delete globals from the foreign wiki
19322:22:55 <legoktm> uh ^ yeah
19422:22:56 <bd808> or rather should not be able to
19522:23:34 <bd808> User rights on the local wiki don't extend across the foreign access api
19622:23:35 <subbu> SMalyshev, i don't think global templates => you have full access to the resource as if on a local wiki .. it is a read-only copied resource.
19722:23:41 <SMalyshev> bd808: but then if you have no redirect (which seems like a viable solution) then looking at Template:Foo if it;s global it would look like local but behave differently
19822:24:08 <SMalyshev> so I think there should be explicit mark in UI to specify it's a copy, not a real thing
19922:24:10 <bd808> sure, just like instantcommons does now
20022:24:32 <James_F> I think transparency is less complex.
20122:24:34 <SMalyshev> (and maybe in non-UI too so that you could make proper UI in apps)
20222:24:58 <DanielK_WMDE> James_F: it is. but is it less confusing? i'm undecided...
20322:25:04 <bd808> attribution of the foreign source seems reasonable and necessary
20422:25:22 <SMalyshev> bd808: that's what I think too
20522:25:27 <DanielK_WMDE> bd808: good point: it's even required by the license.
20622:25:30 <James_F> DanielK_WMDE: Less complex/confusing for users given the existing transparent things we already do, yes.
20722:25:42 <James_F> DanielK_WMDE: Depends on the wiki. :-) But yes.
20822:25:51 <bd808> I'm not hung up on how that attribution is surfaced in the UI
20922:25:55 <SMalyshev> doesn't have to be different namespace, but I think has to be *something*
21022:25:58 <subbu> i think templates are different kind of resource compared to user pages (localized effects to one user) or images (simple uses) and are used more pervasively all over.
21122:25:59 <bd808> "we'll figure it out"
21222:26:00 <robla> we're down to the last 5 minutes of the meeting time. we can continue the conversation on #wikimedia-tech at 22:30 UTC
21322:26:05 <subbu> so, i think explicit namespace is better.
21422:26:18 <bd808> #idea attribution of the foreign source seems reasonable and necessary
21522:26:45 <TimStarling> I think transparently including templates would give you an interface where there are unintended consequences of user actions
21622:26:50 <bd808> #info TimStarling and subbu favor an explicate foreign template namespace
21722:27:11 <subbu> typo :)
21822:27:19 <TimStarling> that's why I don't think it is simpler for users
21922:27:20 <bd808> heh
22022:27:25 <TimStarling> it is simpler until it goes horribly wrong
22122:27:42 <SMalyshev> TimStarling: exactly
22222:27:44 <bd808> the namespace manes sense as long as redirects can "hide" it from most users
22322:28:05 * robla thinks several programming languages should have that slogan ;-)
22422:28:18 <robla> "it is simpler until it goes horribly wrong"
22522:29:18 <duploktm> sorry, my internet kind of died
22622:29:25 <robla> are we going to end on my bad joke note? ;-)
22722:29:37 <duploktm> :P
22822:29:46 <duploktm> thanks for the discussion and input everyone
22922:29:53 <robla> duploktm: I think we're just about ready to wrap things up. 30 second warning
23022:30:10 <robla> 10 seconds....
23122:30:24 <robla> great meeting, thanks everyone!
23222:30:29 <robla> #endmeeting

Links for the next 4 meetings:

daniel renamed this event from RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office) to ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office).Nov 21 2016, 6:11 PM
daniel changed the host of this event from RobLa-WMF to daniel.
daniel invited: ; uninvited: .
daniel updated the event description. (Show Details)
daniel updated the event description. (Show Details)Dec 9 2016, 7:44 AM
daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office).