The current interwiki transclusion feature is far too slow and unreliable to be
used for this application.

It is not like the templates will be altered. Can you be a bit more specific by
what you mean by "slow"? Which block of code determines the speed of this?

ayg wrote:

See bug 9890.

RSYQFIOJGWZA wrote:

A disadvantage is not being able to find something that was ambiguously transcluded. However, only having to look in one other place makes this not such a bad thing. :)

OTOH, this would mean adding a fair amount of useful templates (like non-Babel userboxes and project-specific formatting templates like http://en.wikipedia.org/wiki/Template:Go ) to Commons that wouldn't normally fit its scope, so its scope might have to be adjusted to accommodate them.

RSYQFIOJGWZA wrote:

To be clear, I ask that you please choose to enable $wgEnableScaryTranscluding. I'm not sure if that means you just have to enable it on Wikimedia Commons to be able to transclude from there, or if it also means that you have to enable it on English Wikipedia (for example) to be able to transclude to there.

ui2t5v002 wrote:

(In reply to comment #14)

Where is the problem using "{{commons:template name}}" or "{{c:
template name}}"?

Well, I was thinking it would be like images:

• If you include an image that only exists on Commons, it uses the Commons version. If your local wiki has an image under the same name, the local version overrides the Commons version. If you move an image to Commons, you delete the local version so the Commons version is used.
• If you transclude a template that only exists on Commons, it uses the Commons version. If your local wiki has a template under the same name, the local version overrides the Commons version. If you move a template to Commons, you delete the local version so the Commons version is used.

Typing out "Commons:" for every trivial template would not be very good.

What about interwiki transcluding a non-template namespace page? Templates are fundamentally different form images.

Having said that, I like your idea.

How about doing both? if {{name}} links to a nonexistant page check commons else overide

if {{commons:name}} check commons

redlinks would only form if a commons version doesn't exist, much like images.

ui2t5v002 wrote:

(In reply to comment #24)

What about interwiki transcluding a non-template namespace page? Templates are
fundamentally different form images.

Yes. Think about the Help pages that are regularly updated from meta. This could be applied to things like that, too.

How about doing both? if {{name}} links to a nonexistant page check commons
else overide

if {{commons:name}} check commons

Hmmm

redlinks would only form if a commons version doesn't exist, much like images.

Templates don't create redlinks, though? If {{Template:fgdsafds}} doesn't exist, it just renders as {{fgdsafds}}, no?

robchur wrote:

(In reply to comment #25)

Templates don't create redlinks, though? If {{Template:fgdsafds}} doesn't
exist, it just renders as {{fgdsafds}}, no?

No, that's incorrect. Non-existent templates render a link to the template page.

*** This bug has been marked as a duplicate of bug 1126 ***

rotemliss wrote:

It is not a duplicate. Bug 1126 is about the possibility to do that in the software; this bug is about enabling it in Wikimdia sites.

Wiki.Melancholie wrote:

Concerning the interwiki linking optimization:

• [[m:A new look at the interwiki link]]
• [[m:A newer look at the interwiki link]] [!]

Wiki.Melancholie wrote:

Any status update?

To see how to handle dates/all kind of numbers in a "database" manner:
[[Template:Latest_stable_software_release/Mozilla_Firefox]]
{{release date and age|2008|09|26}}
http://en.wikipedia.org/w/index.php?title=Template:Release_date_and_age&action=edit

• Bug 16575 has been marked as a duplicate of this bug. ***

mike.lifeguard+bugs wrote:

Nothing to do on shell until bug 9890 is fixed - removed that keyword.

To summarise:
The feature required was provided under bug 1126, but not well enough so bug 9890 (making it good) need to be resolved first.
However do we know exactly how poor the fix at 1126 is?

Since we can do commons images it seems not a leap of faith to allow flat text transclusions without grinding the servers.

(In reply to comment #33)

However do we know exactly how poor the fix at 1126 is?

Really really nasty.

Bug 9890 (hopefully fixed with GSoC this past summer) remains an absolute blocker to this, IMO.

rehman.wikimedia wrote:

Really wished this feature existed. A good way around its usage is explained at comment #23 and comment #24.

Any clue on what is the current status?

(In reply to comment #35)

Really wished this feature existed. A good way around its usage is explained at
comment #23 and comment #24.

Any clue on what is the current status?

Still waiting on Bug 9890. My (probably superficial) understanding is that Peter made some excellent progress during GSOC, but the interwiki transclussion code is still not quite ready to be flipped on at commons.

peter017 wrote:

My code (in the 'iwtransclusion' branch) needs to be merged with the trunk. I hope this will be done soon after 1.17 is released.

All my contributions can be seen here: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/peter17

Please let me know if there are some commits I have to correct in order to facilitate this merge.

So I understand that central langlinks and central templates will no longer be seperate systems but both use the same.

I think that's great since this way more can be transcluded in the bottom of the article.
For example:

• {{fa}} (Featured article)
• {{commonscat}} (Category on Commons with images about this subject)
• {{wiktionary}} (Page on Wiktionary with grammar, definitions, translations about this subject)

Ofcourse these templates may not exist on all projects, but that's exactly where the other usecase of this system comes in, they can exist in the central place as well.

A few important questions imho though

• Is this going to be on Commons ?
• Although both will use the same system, if not on Commons. Will central templates and langlinks be stored on the same wiki ?
• Will it fallback to Commons, like with images ? (ie {{fa}} will transclude local Template:Fa and otherwise Commons' copy of {{fa}}, and using {{commons:Template:fa}} will always use Commons's version). Or should there be no such fallback (why not?) and must there be a iw-prefix ?
• Should we disallow transclusion from other projects and only from one ? if not, why ?
• Should we disallow transclusion from non-Template namespaces ? If not, why ?

Just for the record, other examples of great localized templates on Commons:

• {{Information}}
• Licenses
• more..

rehman.wikimedia wrote:

(In reply to comment #38)

Will it fallback to Commons, like with images ? (ie {{fa}} will transclude
local Template:Fa and otherwise Commons' copy of {{fa}}, and using
{{commons:Template:fa}} will always use Commons's version).

IMO, if there was good reason of why such a fallback ({{commons:Template:fa}}) was not implemented for images ([[Commons:File:Fa.jpg]]), then it should probably apply to templates too...

Should we disallow transclusion from other projects and only from one ? if
not, why ?

IMHO, I think Commons should be the only "repository" of content. Enabling full cross-wiki transclusion would create unnecessary confusion...

Should we disallow transclusion from non-Template namespaces? If not, why?

I think we should allow that; don't see any strong reason why it shouldn't be allowed...

rehman.wikimedia wrote:

Don't know how far it's possible, but maybe (upon enabling cross-wiki transclusion from Commons), we could also create an option in [[Special:Preferences]] where checking it would transclude the Commons userpage to all other wikis.

For example, checking it would simply replace the userpage with a function like {{User:Rehman}} (or {{Commons:User:Rehman}}) on all other userpages...

rehman.wikimedia wrote:

(In reply to comment #37)

My code (in the 'iwtransclusion' branch) needs to be merged with the trunk. I
hope this will be done soon after 1.17 is released.

Just wondering, whats the current status of this feature (now that 1.17 is deployed)?

(In reply to comment #41)

(In reply to comment #37)
> My code (in the 'iwtransclusion' branch) needs to be merged with the trunk. I
> hope this will be done soon after 1.17 is released.

Just wondering, whats the current status of this feature (now that 1.17 is
deployed)?

You may be interested in the thread on wikitech-l: http://lists.wikimedia.org/pipermail/wikitech-l/2011-March/052047.html Sounds as if things are moving along (but I don't know anything beyond what was said in that thread)

Automatically transcluding templates from Commons without some kind of namespace addition ('commons:') would be a bad idea in my opinion. There are templates that exist on Commons that are specifically deprecated on other wikis due to differing policies. For example, the GFDL-1.2 template is deprecated on both the German and English Wikipedias but is still allowed on Commons.

Re-scoping bug, since I actually see no discussion about enabling it on commons or consensus for it linked either.

Set priority back to low. Previous change didn't have any motivation and bug is still unassigned.

(In reply to comment #43)

Automatically transcluding templates from Commons without some kind of
namespace addition ('commons:') would be a bad idea in my opinion. There are
templates that exist on Commons that are specifically deprecated on other wikis
due to differing policies. For example, the GFDL-1.2 template is deprecated on
both the German and English Wikipedias but is still allowed on Commons.

Ryan, I don't see why this would be an issue. If a specific template on Commons is unwanted locally, just create and lock a local template (something as simple as "This template is deprecated"). Then, the Commons template will never be available locally. Given that the non-viability of a Commons template would have to be determined on a case-by-case basis, I don't see why this would be any real hardship on the local projects. I would imagine that such situations will be fairly uncommon.

Since p858snake rescoped this bug on April 19, this bug is just about the technology. Discussion about the possible implementations (e.g. Commons) should occur on strategy or meta, or mailing lists.

rehman.wikimedia wrote:

(In reply to comment #47)

Since p858snake rescoped this bug on April 19, this bug is just about the
technology. Discussion about the possible implementations (e.g. Commons)
should occur on strategy or meta, or mailing lists.

There is currently an open discussion at Commons: http://commons.wikimedia.org/wiki/Commons:Village_pump#Commons_also_as_a_repository_for_templates_and_pages

rehman.wikimedia wrote:

As per the above discussion (Commons link), there seems to be a strong community support in enabling the feature.

Although, there were a few opposes for turning Commons as "the" template repository, but that of course, is unrelated to what is/was being discussed.

Ps. I have rescoped/restored the importance scale to as of 2011-03-12.

(In reply to comment #49)

Ps. I have rescoped/restored the importance scale to as of 2011-03-12.

Please do not do that unless you intend to provide the code to actually make this happen. If you do, please assign this bug to yourself.

rehman.wikimedia wrote:

(In reply to comment #50)

Please do not do that unless you intend to provide the code to actually make
this happen. If you do, please assign this bug to yourself.

My apologies, thought it should be high when you have consensus or such. My bad.

(In reply to comment #50)

> Ps. I have rescoped/restored the importance scale to as of 2011-03-12.

Please do not do that unless you intend to provide the code to actually make
this happen. If you do, please assign this bug to yourself.

Please point me to the wmf policy that prescribes that a bug may only be important if already someone is willing to tackle the problem. Logically it seems the other way round: If a bug is important it is on the list of work to start, whereas a low priority enhancement is likely to be never started.

(In reply to comment #52)

(In reply to comment #50)
> > Ps. I have rescoped/restored the importance scale to as of 2011-03-12.
>
> Please do not do that unless you intend to provide the code to actually make
> this happen. If you do, please assign this bug to yourself.

Please point me to the wmf policy that prescribes that a bug may only be
important if already someone is willing to tackle the problem. Logically it
seems the other way round: If a bug is important it is on the list of work to
start, whereas a low priority enhancement is likely to be never started.

Take a look at this wikitech-l topic:
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/53292/match=bug+priority+assigned+highest

Also reflected at http://www.mediawiki.org/wiki/Bugmeister/Bugzilla

(In reply to comment #52)

If a bug is important it is on the list of work to start, whereas
a low priority enhancement is likely to be never started.

I can see what you're saying, but I've also also posted lists of bugs on WikiTech-l and used this to point developers towards bugs that they could work on. If you think a bug should have attention, see my suggestions for how to make that happen at http://hexmode.com/2011/04/a-philosophy-of-bugs-on-an-open-project/

Not sure if this comment should here or on bug:9890 but if/when this is enabled what will happen if a user unknowingly creates a local template at the same name as a Commons one? Will there be an "are you sure you want to create this?" or something? i.e.

Scenario 1:
en.wp is using Commons:Template:Foo, called just as {{foo}} as there is no local Template:Foo page.

user:bar creates template:Foo on en.wp to do a completely different job, not knowing that a template:Foo from Commons is in use elsewhere on the project.

other users see that template:Foo is now doing a very different thing to what it did and start complaining everywhere they can think of complaining.

Confusion and bad feeling ensue.

Scenario 2:
en.wp is using Commons:Template:Foo, called just as {{foo}} as there is no local Template:Foo page.

user:bar creates template:Foo on en.wp to do a completely different job, not knowing that a template:Foo from Commons is in use elsewhere on the project. When she tries to save to save it a message informs her that a template of this name exists on Commons and is she sure she wants all uses of it on en.wp to use this version instead? [Yes, all pages on en.wp should use this template] [No, use a different name for this template] [Cancel]

user:bar saves her template as Template:Foo2

Scenario 3:
Template:Baz is transcluded from Commons onto a large number of pages at en.wp.

malliscious user:Quux on en.wp creates a local template:Baz consisting of an image that fills the page. When he tries to save it he is presented with same message as in scenario 2. He clicks that yes.
Pages on en.wp are replaced with the image the next time they look at the template. Other users start complaining everywhere they can think of while admins scurry to find and fix the problem.
User:Quux is banned and moves on to is.wp and repeats.

How do we stop this?

In my opinion, transcluding templates from Commons from another local wiki should be done only explicitly (i.e. the Commons prefix should be needed).

One major problem: the translated template from Commons will often be designed itself to transclude other templates from Commons itself, using names that are supposed to be resolved in the template namespace of Commons only.

Such transclusions that should remain internal to Commons should not be resolved on the local wiki, UNLESS the template on Commons EXPLICITLY says that it allows a local wiki to use its local version (for example a translation, or some alternate cisual formatting matching the look and feel or behavior of the local wiki, or its structure : e.g. names of a local or help page or project page or discussion page, or links to local policy decisions). In my opinion, templates from Commons that can be translated locally on other wikis, should only reference templates using a standard prefix (possibly in a specific namespace distinct from "Template:").

Then, why not implementing simply a separate "crosswiki:" namespace to avoid all these caveats, and which may have policies clearly separated from the usual "template:" space ? After all it would be quite similar to the "mediawiki:" namespace which contains also shared ressources with distinct policies (in other words, the "crosswiki:" namespace that would be transcluded from all local wikis using the shared implementation, or a few local overrides, would have a user policy coming from Commons and NOT from the various local wikis (not even local admins, if they are not admins in Commons).

And to allow creating or editing local overrides of a "crosswiki:" template in any local wiki, the user would first have to be ALSO logged in as a Commons user (SUL will help), so that his edit privileges will be checked on Commons and not locally. In the local template history though, that user will will be listed using his local account name. This edit will not be propagated to Commons, but all registered Commons users that can edit a "crosswiki:" template there, and that have a SUL account will be able to review and edit a local override.

For completeness, a local override of the "crosswiki:" template should be deletable or protectable on a local wiki by making it transclude explicitly the template from Commons (for example using explicitly "{{commons:crosswiki:name}}" with the "commons:" prefix. This will avoid unexpected creations of local overrides, because they are not listed when edited in the history of the crosswiki template of Commons, unless this "crosswiki:" namespace is explicitly manged so that all edits of a local override will also cause an history line to be inserted as well on the Commons history for the same namespace, using the user account that the local user also has on Commons (remember: the condition to edit in "crosswiki:" is that the local user has a SUL account connected to Commons and is authorized on Commons too to perform this edit).

matthias wrote:

I should have known that this has been discussed before. Anyhow I created http://meta.wikimedia.org/wiki/GlobalTemplates with my ideas. By the way: this is already available at Wikia which is a big MediaWiki farm so it might work well under load.

Just an idea, can/will this be possible through the new wikidata system?

content hidden as private in Bugzilla

There is an iw-transclusion branch, which (once finished and polished up) will become an extension that allows tranclusion of wikitext templates from a central wiki (e.g. suppose it would be Commons, then you could use the nicely-translated, micro-formatted {{cc-by-sa-3.0}} on any wiki.

The wikidata system will make it possible to "include" data from another wiki (the wikidata wiki), but that's very different. That will not include wikitext but structured data (e.g. facts, dates, numbers, lists etc.) mostly for usage in articles, infoboxes etc.

The wikitext templates are not something I think will or should be coupled with "wikidata", those are two very different things. Of course on this template-repo wiki you can create a template called "Template:JohnDoe-birtdate" and put "1970-01-01" in there, but thats silly since that is what wikidata is for (dealing with identification of objects, properly formatting it in the localized dateformat, dealing with multiple-value lists etc. references, sources and what not).

thejeremy.net wrote:

Please enable this, it would be very useful.

once again, the "crosswiki:" namespace concept should be explicitly used to allow local overrides.

And most complex templates should now use Lua modules for most of their work, and these modules which should be usable across wikis, and internationalisable locally using local template overrides (they are still needed for formatting, notably between RTL and LTR wikis or wikis using other scripts than Latin which have their specific needs such as date and number formats, or their own presentation conventions: you cannot use the same presentation between Wikipedia, Wiktionary, Wikinews, Commons/WikiAtlas, WikiVoyage...).

There should be now a limited need for crosswiki templates, but a much larger need for crosswiki modules.

internet.guilherme wrote:

Would be nice if we could transclude any "page" (not just "templates") from whatever "project site" its enabled. We need to reuse the content across wiki projects (wikipedia, wikibooks, wiktionary, wikiversity, etc.).

MWF projects and reuse of content

Particularly I'm most active in the pt.wikibooks. And I can tell that, every time I see the need to transclude the "definitions" from wikipedia, wiktionary, etc., to some books. But as we can't, the content end up being "duplicated" once again, in every book that its needed.

The Wikibooks community (and others beyond wikipedia) has much less people than wikipedia, they can't do everything "alone". For you see, in the pt.wikibooks project, a high amount of books periodically gets abandoned (people don't find anyone to help them). If they could "reuse" the content of the wikipedia, wiktionary, etc., more "easily", I think this would improve.

We need to think "reuse of content" as we think "reuse the code" (in the software).

• Bug 53567 has been marked as a duplicate of this bug. ***

Indeed, that would be usefull at Wikiversity too.

This feature would be extremely useful in wikipedia! Most of templates in wikipedia are translated from other language (mostly, from English) and after some time, they just become outdated. There must be one place, where templates can be stored with easy translation tools (like "Translate" extension).

This task is here for 10 years! Does it really have "high" priority? There is even noone assigned to it.

This task is here for 10 years! Does it really have "high" priority? There is even noone assigned to it.

It's high priority because it's the first thing one should do when starting work on this MediaWiki core component i.e. templates. However, nobody has been working in this area for a while.

This task is imho perhaps the most important piece of independent development that could be performed at this point. I'm thinking in particular about the new Graph extension, the rolling-out of which is bound to result, over time, in hundreds of different Lua wrappers on all the hundreds of different Wikipedias. Surely it would be better and more expedient to have one set of commonly agreed-upon and styled wrappers hosted on Meta accessible to all?

This could also give Meta more of a purpose, of course, but this is something that's been discussed again, and again, and again...

Nonetheless recent events have made this task ever more critical. I'm guessing from the history here that the 'iwtransclusion' branch is at this point abandonware?

(I am aware that the scope of this bug is technically templates only, but Lua has long since made templates and their core modules inseparable)

In T6547#1360457, @ResMar wrote:

Nonetheless recent events have made this task ever more critical. I'm guessing from the history here that the 'iwtransclusion' branch is at this point abandonware?

Not necessarily. It was originally merged into core during the SVN days, when code review happened after merging. In this case, there were enough flaws that the code was deemed unsuitable for the impending release of MediaWiki 1.19, so it had to be reverted. However, the last few comments at https://www.mediawiki.org/wiki/Special:Code/MediaWiki/95396 are quite optimistic, so I wouldn't write it off completely.

In T6547#1236830, @Kanzat wrote:

This feature would be extremely useful in wikipedia! Most of templates in wikipedia are translated from other language (mostly, from English) and after some time, they just become outdated. There must be one place, where templates can be stored with easy translation tools (like "Translate" extension).

Maybe than we can store templates in other project and import them to our projects. Templates are always a big mess. Even youd like to share them between different languages, you have allways to figure out, of which components such template consist, to import all its components and customize them to your language. Maybe having that on a separate project like mediawiki.org would ease their usage.

I suggest that the best approach would be to have all templates stored on Meta with individual languages' translations stored as subpages using Meta's translation facilities. As here, for example. There could be a new template transclusion prefix ({{iw:Template}} for instance) which returns the appropriate translation subpage based on the language settings of the current wiki.

A stopgap solution would be writing a script running off of labs that would propagate changes in a master template to all child templates across the wikis once per day, or perhaps once per hour, or however often that could be done.

It looks like the WMF preferred method for achieving this is via Shadow namespaces. See T91162

However it's done this is long overdue but I can't find any indication that it's going to happen.

In T6547#1498830, @robkam wrote:

It looks like the WMF preferred method for achieving this is via Shadow namespaces. See T91162

Not really, if you look at ACTION there.

Regardless of the method, mediawiki.org would fit better as source repository than Meta. Commons is for media, mediawiki.org is for software, and templates are software. This makes even more sense if third party MediaWikis can pull those templates remotely, just like they can pull now images from Commons.

Well... that is/will be a little confusing because we also have the request T59336: Make metawiki the central OAuth wiki.

See also T3126.

In T6547#1362094, @TTO wrote:

In T6547#1360457, @ResMar wrote:

Nonetheless recent events have made this task ever more critical. I'm guessing from the history here that the 'iwtransclusion' branch is at this point abandonware?

Not necessarily. It was originally merged into core during the SVN days, when code review happened after merging. In this case, there were enough flaws that the code was deemed unsuitable for the impending release of MediaWiki 1.19, so it had to be reverted. However, the last few comments at https://www.mediawiki.org/wiki/Special:Code/MediaWiki/95396 are quite optimistic, so I wouldn't write it off completely.

Its probably bitrotted beyond belief at this point. It would probably have to be mostly rewritten in order to keep up with changes in core since it was written.

My point was that the approach and ideas in that code could still be very useful today for anyone who was going to go ahead and reimplement this.

In T6547#1605539, @TTO wrote:

My point was that the approach and ideas in that code could still be very useful today for anyone who was going to go ahead and reimplement this.

Oh certainly. I just don't want anyone to get the wrong impression that all they have to do is just fix a couple lines and hit the submit button. There's quite a bit of work to be done.