Talk:Requests for comment/Shadow namespaces

Previous page history was archived for backup purposes at Talk:Requests for comment/Shadow namespaces/LQT Archive 1 on 2015-07-10.

"This is a request for comments regarding implementing shadow namespaces, which refers to the concept where if a local page doesn't exist, it will be transparently fetched from a remote wiki, like how InstantCommons and foreign file repos currently work." ----> Templatepedia, similar to Commons, but for templates. Or using gtemplate in Commons to crete them and in sister project to use the global template. BoldLuis (talk) 13:43, 12 May 2020 (UTC)

One main use-case I hope we can consider/solve, is that of: Documentation page redundancy/forking.

E.g.

• to have m:Help:Link (/de /fr etc) as the central page,
• which is transcluded to w:Help:Link (etc: d:Q5257102)
• but where local addendums can be inserted. (ideally at a per-section level, to allow hatnotes and other complexities)

This would (mostly?) solve the issue of "important updates need to be done at every wiki, but rarely are", and get more editors collaborating on improving the core docs rather than focusing on their home wikis quite so much.

+1

I was thinking to that example as well. I left dozens of messages everyday because of the current dispersion.

I left a message in on the talk page.

I think this would be fantastic if it happens. There is an enormous difference in the standard of help pages between wikis. It would be really useful to have fall-back pages the sane way that we now have global user pages.

Followup: The idea was discussed in the IRC RfC meeting (transcript at phab:E162#1780) but thought to be a vastly more complicated use-case, and that it might be better to tackle it with it's own RfC focused around improvements on forking/joining mechanisms. (IIUC! I won't attempt to interpret the technicalese any further than that.)

What about on the page saying (excuse my poor parser logic) #ifexist:{{help:this/local}}|{{help:this/local}} - if there is a local page, transclude it

Wikia has had this functionality for Lua for several months, although it is likely not used as much as it would be in wikipedia or other similar farms / wikis. The system seems to work reasonably well. Basically, all modules can either be hosted locally in a particular wiki or in dev.wikia.com and must be explicitly loaded using a syntax like "require ("Dev:Arguments")". This fetches modules from dev.wikia and uses them in a different wiki, e.g. templates.wikia.com. It also allows a mix of local and foreign modules, so if a script from the central repository doesn't explictly use the Dev:Arguments syntax, it tries to fetch the module locally.

I think this brushes over the licensing issues a little too quickly.

Does transcluding a foreign CC-BY-SA template mean the destination page has to be CC-BY-SA (probably, but IANAL)? I would say certainly if subst: is used (but still IANAL).

If so, even in the Wikimedia context, there are some possible issues. E.g. English Wikinews is under CC-BY 2.5, not CC-BY-SA 3.0. CC-BY-SA content can't be imported into a CC-BY wiki.

This doesn't block the feature. But depending on the answers to these questions, we might need some kind of metadata on the repositories. We could try to check simple known cases (e.g. CC-BY-SA on both, or CC-BY on the source, CC-BY-SA on the destination), and allow the admin to override it in case we got it wrong or they received different legal advice.

I don't think we should just expect each sysadmin to solve this properly on their own.

For templates, I kind of feel like interwiki namespaces would be a better fit then just totally shadowing. Someone could write {{wikipedia:Foo}} if they wanted to include an external template.

Also, how will things like {{SERVER}} et al, be rendered from a foreign template. What about extensions on the foreign wiki but not the local wiki. Do template invocations on the foreign template invoke the foreign version or the local equivalent? Are categories translcuded cross-wiki? Do foreign interwiki links that aren't local interwiki links render properly?etc

During the IRC meeting (logs), we discussed that there were two parsing types, remote parsing and showing the rendered content, or local parsing and evaluating the remote wikitext. InstantCommons and GlobalUserPage currently use remote parsing, and that would also be suitable for global help pages. But for templates and Scribunto modules, we would want local parsing.

"When a new version of a file is updated on Commons, it will automatically update on InstantCommons sites since images are hotlinked.[citation needed]"

InstantCommons caches thumbnails and file description pages locally for a few hours (see Manual:$wgUseInstantCommons for specifics); there is no invalidation mechanism.

I have no idea what this RfC is talking about. It seems to be a duplicate of m:Requests for comment/Global bits and pieces but then I'm not sure why it's called "Global scripts". There is a section "Existing" which talks of totally unrelated things, then "Scopes" which is not about scripts.

I suggest to make it an RfC about global templates or about global gadgets. Any RfC about global templates is useless until someone enables and tests $wgEnableScaryTranscluding somewhere, reporting back with field-tested issues rather than philosophy.

Well global templates rather strongly implies global Lua modules, which should probably be done at the same time (or at least, with the same decisions) as global gadgets. But I do agree that this feels a bit too much like the wrong venue; is this asking about how we would technically achieve it, or are we talking about providing it to Wikimedia wikis? If the latter, this is the wrong place for this discussion, and it's far too narrow in engagement.

Yeah, I noticed similar issues with this RFC last evening as well. I'll do some cleanup.

Indeed James, so true that I think "global templates" implies "global modules" automatically. :)

Thanks MZ, much clearer now. "Shadow namespaces" are what was proposed as "global namespaces" in 2012 by Rd232, tracked at phab:T66474.

I still think that some serious testing of scary transclusion should come first, because we have no real evidence that it's still problematic: in fact, there are wikisource domains which are already doing crosswiki transclusion via terrible hacks and it still works rather well.

In addition, I'd take out of this the things which work rather well simply by HTML transclusion (as DoubleWiki does too, more or less), in particular user pages. Lego's work on Extension:GlobalUserPage can be put into use very soon and doesn't need rethinking.

I think all of this would be great. Wikidata is reaching a point where it has enough translations for specific property names contained in infoboxes that many templates could be made global (translated automatically). This would simplify a lot of scenarios for content growth and synchronization within templates, like when you want to add a new property to an existing template. As far as locations for storing them, I would be comfortable with putting global templates and modules in Commons (I generally support expanding the types of media that can be stored there, like 3D meshes, etc) and putting global gadgets on MediaWiki. Wakebrdkid (talk) 00:34, 10 July 2013 (UTC)

Mediawiki.org is probably the best place because it is where is easier to find programmers. Besides that will finally unite the community of programmers from several wikis with the developers of MediaWiki.

I do not see another strategy that is better than this for the 'Engineering Community team' get skilled labor.

Regards!

In the following quote: "A lot of this depends on....", what does this refer to? From the links to bugzilla I can gain context, but it's somewhat confusing to start out a page with a pronoun that doesn't reference anything.

I'm in favor of both implementations mentioned in your bug — I'm not convinced those solutions are mutually exclusive.

I think I viewed them as mutually exclusive, so certain considerations were contingent upon whichever implementation was chosen. Maybe. Feel free to edit the page if the language/wording could use improvement. :-)

I suppose you're correct that we could support both implementations described at bugzilla:39610#c0, though. Maybe.