Last modified: 2014-11-17 09:21:03 UTC
It should be possible to include templates that are stored on Commons. Just like we can do with images! This would be for centralized templates. Examples would be: 1. Templates for interwiki links (interlanguage links); this would make the interlang bot activity almost unnecessary. 2. Templates with current information like software versions, etc. There is much more application range, of course. This would help reducing redundancy! Currently all the work that is the same in every wiki has to be done xxx-times. With template inclusion from Commons enabled we only have to do that once. The template names could be in English, or in the language of the creator (who comes first...). Best regards, Melancholie
see bug 1126 about interwiki templates
Yes, but the bug 1126 is in the MediaWiki section and the feature has not been enabled for Wikimedia projects (for unknown reasons). I want to have this feature available for Wikimedia, too. This would have big advantages for us! Best regards, Melancholie
I strongly support the activation of this feature. Last weeks I was thinking about making Babel templates BiDi compatible and localising them. Beside using generic namespaces in the templates one could use local pseudovariables as {{BABELUSER}} to generate [[fr:Catégorie:Utilisateur en]] using {{BABELUSER}} == 'Utilisateur' and [[category:{{BABELUSER}} en]] at [[fr:]]. Details can be solved later: [[zh:Category:En 使用者]] could be solved using [[category:{{BABELUSERHEADER}} en {{BABELUSERTRAILER}}]]. If the feature is activated the templates should be "reviewed". Issues known to me which can cause problems are: a) InterWiki's are not the same at all Wikimedia foundation projects b) some projects are using custom namespaces ([[meta:]], [[commons:]], bug 1676 [[de:]], [[en:]], [[fr:]], [[n:ja:]], bug 3385, bug 3736, bug 3818, bug 4113, bug 4135, bug 4143, bug 4155, bug 4247, bug 4297, bug 4311, bug 4369, bug 4562 c) BiDi compatibility see http://wikisource.org/wiki/Template_talk:InterLingvLigoj#template:InterLingvLigoj_and_BiDi_issues If performance will become an issue one might use "subst:" or can implement bug 2777: request for a {{substall:foo}} beside {{subst:bar}} best regards reinhardt [[user:gangleri]]
d) font families, style, size etc are different at [[ko:]] etc. e) case sensitivity at other projects (Wiktionaries) *addendum* (template) portability could be achieved with redirects. example: [[fr:template:utilisateur_en]] should redtirect to [[fr:template:user_en]] and not viceversa; this way xx.project..org/w/index.php?title=template:user_en&action=edit is an "universal" link
If font families, styles, sizes or language expressions are different, we can use tricks like "{{{1}}}" and for dates "2006-07-30" e.g. But first it is essential to have this feature enabled, where there are no disadvantages as I see.
Better English, I think: ...due to no disadvantages, as I see.
(In reply to comment #6) > Better English, I think: > > ...due to no disadvantages, as I see. I see no problem using redirects, especially for languages using non-latin alphabets. I tested this extensively. ---- re: a) I was thinking about the interwiki prefixes "wikipedia:", "wikibooks:", "wikinews:", "wikiquote:", "wikisource:", "wiktionary:", "commons:", "meta:" which are project namespaces in some projects f) some templates require similar configurations in "MediaWiki:Monobook.css" and / or "MediaWiki:Monobook.js"; the "show" / "hide" Java code is a typical example
This bug would be extremely handy. But I think it shouldn't be included like normal templates; it should have a prefix like commons:, or if used for interwiki, interwiki: instead. That way there won't be a crash between local templates and commons templates. The only disadvantage about having interwikis that way would be that it's harder to find. People won't know where to look for it; should the templte names be in English, or the first language to get an article on the subject? But all in all it's a good change.
Changing summary to reflect that this is a configuration request.
It would be extremely handy for Babel, and there, the template naming wouldn't constitute a problem.
(In reply to comment #8) > The only disadvantage about having interwikis > that way would be that it's harder to find. And would require every template to have {{commons:template name}} before it? I don't like that. Then again, templates with English in them wouldn't be used by other language pedias, so maybe this would only apply to styling templates and the like?
Many advantage of this feature, such as same template can be used across projets, templates in en.wiki can be used in wiktionary, wikiquote, wikibooks, wikisource. And If you contribute to lot of wiki, you can create one template for all of your user pages.
(In reply to comment #12) > If you contribute to lot of wiki, you can create one template for all of your > user pages. Well, that should really be done with interwiki redirects, no?
(In reply to comment #11) > And would require every template to have {{commons:template name}} before it? > ...so maybe this would only apply to styling templates and the like? Where is the problem using "{{commons:template name}}" or "{{c: template name}}"? Until now a plenty of interwiki links has to be added in every different language wiki (often by bots), and this every time a new language wp has created an article about XY. All this work would disappear with common templates. And the naming of the Template on Commons does not matter! The only important thing is, that the template -has- a title ;-) But maybe a new namespace would be the best for Commons! Something like "Interwiki:" that would behave like the 'Commons-internal' template namespace, of course (no mentioning of prefix needed when adding). !Or much better: "Wikipedia:", "Wiktionary:", etc. to have a namespace for every project individually. Then there could be a namespace "Interproject:" for cross-project templates! For different styling or different language lettering parameters ("{{{1}}}") can be used, for example. But like I wrote, I think of centralising the software versions and release dates (2006-01-26) in Template:Infobox_Software and all other figures and dates that has to be changed in every single wiki to keep them up-to-date, centralising (some of) the Babel templates, and so on. There are no drawbacks in enabling this feature, because when there are individual problems with any templates, nobody is forced to centralise that template ;-)
(In reply to comment #14) > ... !Or much better: "Wikipedia:", "Wiktionary:", etc. to have a namespace for every project individually. Please see http://commons.wikimedia.org/wiki/User:Gangleri/tests/bugzilla/04547#wikipedia_bugzilla_04547 If a template starts with an interwiki prefix the template must be called with {{template:<template_name>}} and *not* with with the short form {{<template_name>}} because last is ambiguous. The idea having special namespaces for transcuding "templates" for different projects (wikipedia, wikibooks, etc.) would expand the original request to "Enable transclusion from commons" because most likely every page from every namespaces can be transcluded or special flags for the namespaces to be transcluded at commons must be set. best regards reinhardt [[user:gangleri]]
(In reply to comment #15) > "Enable transclusion from commons" because... Yes, that was exactly what I did want. I did not want to have this feature restricted to interwiki templates for Wikipedia, only! Changing summary...
Complete support. License templates, Babele templates and other similar templates should be uniform on all projects. This would serve that purpose.
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?
See bug 9890.
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.
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.
(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.
(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?
(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 ***
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.
Concerning the interwiki linking optimization: * [[m:A new look at the interwiki link]] * [[m:A newer look at the interwiki link]] [!]
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. ***
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.
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.
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..
(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...
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...
(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.
(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
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.
(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).
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?
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).
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.
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.