Requests for comment/Interproject links interface

This is a subpage; for more information, see the Requests for comments page.

Interproject links are the set of links that convey to the user the existence of pages relative to the subject in other sister projects (Wiktionary, Wikisource, Commons, etc.). This RFC has the aim to ask the communities for their opinion on proposed interfaces that would allow storing the interproject links in a central location, such as Wikidata. See also bugzilla:708.

Current situation

Interproject links are represented in several ways depending on the language and on the sister project. However, no matter the project, the links are stored as text. This is a similar problem to interlanguage linking, which is being addressed by Wikidata.

Wikipedia

Wikipedias have tended towards two solutions: either with templates at the bottom of the page, or with an "other projects" link collection on the left bar.

The English Wikipedia normally uses Template:Sister project links, which creates a box with links at the bottom of the page (see w:en:Shakespeare#External_links). On the other hand the Italian Wikipedia uses Template:Interprogetto which places the interproject links on the left-hand bar (see w:it:Dante Alighieri, "Altri progetti"). The Spanish-language Wikipedia uses both links at the bottom and the ledft bar (see w:es:Historia.)

Wikisource

On the Wikisources, besides of the approaches used by Wikipedia, a third one is used on author pages, where the links to other projects are either placed on templates on top of the page (see the French Wikisource s:fr:Auteur:Victor Hugo) or on a infobox on the right side of the page (see the German Wikisource s:de:Johann Wolfgang von Goethe).

Sometimes certain texts contain also links to Wikipedia that are placed either on the left bar, or on an overlaving template (this page on the Catalan Wikisource contains an example of both: s:ca:Enllà, where "Informació sobre el text" links to Wikipedia and on the left bar too).

Wiktionary

Some Wiktionaries prefer to use the "links on the left bar" option. A Wiktionary article may link with several articles in Wikipedia, one for each definition and project (see the German Wiktionary wikt:de:Kind, "Schwesterprojekte:" on the left bar).

Wikivoyage

A Wikivoyage article has links to other Wikivoyage language versions on the left bar, and additionally a link to Wikipedia in the language of the article and a link to the Commons category. The Wikivoyage interlanguage links are currently maintained by bot.

Commons

Certain categories include the Template:Creator, which places the interproject links as icons on top of the box (see Category:Cicero). The links to Wikipedias are just language interwikilinks, but they still don't fetch from Wikidata and Wikipedias still have to link back with manual {{Commonscat}} or equivalents.

Proposals

Since there is a big diversity in uses, there might not be a universal solution for every project. Especially difficult is the case of Wiktionary, where each page can link to several articles.

Other projects like Wikipedia, Wikisource, Wikitravel, Wikiquotes, Wikivoyage, etc. could benefit from an unified system where all the links are centralized in Wikidata in a similar way as now happens with language links.

Option 1: Action/Interproject tabs

Proposal for an interface with tabs for interproject links

This option would place extra tabs linking to the related sister projects.

• The maximum amount of tabs would be to 4 or 3 plus an arrow that would display the extra sister project links. The position of each tab would be kept consistent across projects (if it is meaningful to deploy this interface on that sister project).
• This requires to move the "talk" tab to a new position and maybe some other additional tabs added by sister projects.

NOTE: to avoid the user to get disoriented when clicking on one of those tabs, it is also proposed to transclude the pages from the sister project into Wikipedia (or the relevant project), in a similar way as now is happening with File pages transcluding the file description from Commons.

For more information and mockups check this presentation.

Support

• Support As proposer. It could be a good solution wherever it can be deployed. It doesn't need to be everywhere, Wiktionary could be skipped.--Micru (talk) 01:33, 24 April 2013 (UTC)
• Support Would need some additional thinking, but makes sense. --Nemo 09:27, 24 April 2013 (UTC)
• Support If it's feasible, why not? --Sannita - not just another it.wiki sysop 11:50, 24 April 2013 (UTC)
• Support... though the idea of a Vector tab for each sister-site that happens to host relevant content is a bit overkill (imho). Make it one Vector tab with a Vector menu list of all the sister links (or sister searches if redlink there?) under it and that would be still "easy on the eyes" for those who don't care about such things but a useful addition for those who do. -- George Orwell III (talk) 11:55, 24 April 2013 (UTC)
  • That would reduce the number of buttons, but would also hide the links. Regular users don't click on innocent arrows. --NaBUru38 (talk) 22:28, 24 April 2013 (UTC)
    • Regular users would quickly adopt whichever approach is selected in the end. We want casual visitors to become regular users and linking sister content may just be the way to achieve that. Slap an animated .gif on the tab if you think extra "eye candy" is needed to draw attention to the newly linked sister content. I see little difference between the drop-down menu under a single tab and what is being proposed in option 5 as well. -- George Orwell III (talk) 15:06, 27 April 2013 (UTC)
• Support I'm currently working on a template for the french wikipedia, aiming at providing a a knowledge requirement preview with a list of internel link for each concept, and a list of each relevant course on the wikiversity. I think this is exactly the kind of tool we are missing to provide readers with all information which may be relevant for their current research and to bring more contributors to sisters projects, which do need them in order to improve their content. --Psychoslave (talk) 14:10, 24 April 2013 (UTC)
• Support Making other projects something closer to first class citizens would be one of the most positive steps we could take to re-energize those projects. It will take some serious thinking and design work to figure out how to make it work, given that the correspondence between pages on other projects isn't always one-to-one (there could be many relevant Wikinews articles for one Wikipedia article, or several different Wiktionary definitions, or a whole slew of related Commons categories). But the basic idea of highlight the parallel content on other projects in a high-profile way is totally sound.--Ragesoss (talk) 16:08, 24 April 2013 (UTC)
• Support I rather like the idea of tabs here, but this may require retooling how we expose the talk page since it currently uses that space in the UI. We may also need to do something like how interlanguage links are being done in wikidata to connect pages together based on topics. There's also the open question of what to show if there is nothing linked up -- show a red tab as a call to action to create one? Hide them? Have a subtler, hidden call to action? --brion (talk) 16:14, 24 April 2013 (UTC)
• Support I think this option combines visibility for sister projects with a somewhat discreet appearance. A casual user of Wikimedia is more likely to see the links but they are also easily ignored if unwanted. I would not be opposed to a single tab with a drop-down menu (like the current "Move/Delete/Protect" selection) but the choice of title is important; a casual user will not know what "sister project" or "interproject links" means ("External resources" or just "Resources" perhaps?). - AdamBMorgan (talk) 16:21, 24 April 2013 (UTC)

  Note that the newer "Option 5: Dropdown next to title" also covers everything I'd want with an even more discreet appearance. - AdamBMorgan (talk) 12:07, 25 April 2013 (UTC)

• Support This tabs proposal is great! I'm very interested in helping Wikipedia readers to reach the other projects. But I'd like the tabs to depend on the page: people would get Wikiquotes, writers would get Wikisource, terms would get Wiktionary, etc. --NaBUru38 (talk) 22:12, 24 April 2013 (UTC)
• Support Almost nobody knows about Wikipedia sister projects. There are so many people that invest so much of their time. Time = money. So basically there are so much investment on other sister projects but barely being used by people who need them because not many people know about their existence. This would help maximize all the sister projects utility and maximize its potential usefulness. So in the end, our contributions in sister project are not in vain.Trongphu (talk) 02:09, 25 April 2013 (UTC)
• Support in some form. –SJ talk  03:46, 25 April 2013 (UTC)
• Support--Wvk (talk) 11:17, 25 April 2013 (UTC)
• Support if this gets the most votes, but I'd prefer something more like Option 5. PiRSquared17 (talk) 14:33, 25 April 2013 (UTC)
• Support Excellent idea! It can make other wikimedia project more popular. בנימין (talk) 15:08, 25 April 2013 (UTC)
• Support It seems very sensible to give prominent links to the sister projects, rather than hiding them away at the bottom of the page, or in the sidebar, and this seems like a sensible place to put those links. Mike Peel (talk) 13:17, 26 April 2013 (UTC)
• Neutral I personally think that Option 5 is better, but if it doesn't get enough votes, then let it be this option. Soshial (talk) 19:35, 27 April 2013 (UTC)
• Support as Nemo says below I like the idea of associating actions to tabs, this, at least in principle, could invite more people to participate or just browse within the variety ofprojects. Furthermore I like the fact that sister projects will be in a prominent position. Lastly, I think that experience editors workflow will be changed very little, for new editors I think that seeing more stuff in the tabs maybe will lead to more interest/focus on the area (and maybe more people clicking "Edit"). Adding a note: I think that various test with thabs in different order can be made to see which is more suitable to users. -- CristianCantoro (talk) 21:55, 29 April 2013 (UTC)

Oppose

• Strongly oppose This area of the interface is defined as the namespaces related to a page. Making links there switch to a completely different wiki is very unexpected and very unfriendly towards users. Dantman (talk) 03:45, 24 April 2013 (UTC)
  • The tab layout would be the same in other wikis, hence the user will still have the reference, additionally icons can be placed on the tabs. Another alternative could be to transclude the pages into wikipedia in the same way as now is done with the File pages from Commons.--Micru (talk) 04:02, 24 April 2013 (UTC)
  • It's not about namespaces, it's about actions (in Vector): Read, Discuss. It may make sense to add related actions like "Read books", "Browse media" etc. --Nemo 09:27, 24 April 2013 (UTC)
  • No it's not about actions. Actions are on the right side of the bar. This interface completely removes links to the talkpage and eliminates the language variants. Dantman (talk) 14:40, 24 April 2013 (UTC)
    • Language variants could be either reachable through the arrow menu or alternatively the current system could be kept for special cases.--Micru (talk) 17:25, 24 April 2013 (UTC)
    • Variants do not belong in the same menu as sister projects. And having multiple menus in the same section is counter-intuitive and confusing for readers. Dantman (talk) 00:24, 25 April 2013 (UTC)
  • Now that I see the presentation that shows the talkpage link as moved rather than removed let me rephrase myself; Talk does not belong in the actions tabs. Talk/Discussion is not an action. It's a page in another namespace. And when you go and do something like edit or view the history of the talkpage this is going to lead to the undesirable and confusing behaviour of having multiple action tabs active at the same time. Dantman (talk) 00:24, 25 April 2013 (UTC)
    • We're not speaking of "actions" in MediaWiki terms (action= in the URL), but of things the reader wants to do/is interested in: currently Article (content), Talk (discuss content), Opinions (in some Wikinews languages, even though may be another namespace or not). I agree Talk should not be moved from the left tabs but I don't think there would be any interface inconsistency in principle. --Nemo 08:45, 25 April 2013 (UTC)
• Oppose Having the links in the sidebar makes so much more sence. Having the links as tabs would give the impression that the pages on the other wmf wikis where pages on that particular project.--Snaevar (talk) 11:25, 24 April 2013 (UTC)
• Oppose terrible interface design, breaking users' expectations like that. One click: talk page within the same site. Another click, on a tab right next to it: related page on another site. No, it's bad. And that's without even getting into the upheaval and upset caused by changing interface on many projects - you can just imagine the zillions of editors who won't participate in this RFC being annoyed by this change being imposed. Rd232 (talk) 16:44, 24 April 2013 (UTC)
  • As stated above the page from the other project could be transcluded in the same way as now it is happening with the File pages with information from Commons.--Micru (talk) 17:23, 24 April 2013 (UTC)
    • Where does it say that? Anyway that approach doesn't make any sense to me: it sort of works for files from Commons (with flaws like not showing Commons categories); I don't see it working for other things. Rd232 (talk) 18:19, 24 April 2013 (UTC)
      • Up in the conversation. I will add it to the description too. That files transclusion from Commons has flaws doesn't mean that they cannot be fixed.--Micru (talk) 18:52, 24 April 2013 (UTC)
        • That flaws can be fixed doesn't mean that they will be... Rd232 (talk) 19:19, 24 April 2013 (UTC)
• Oppose Many articles will have a lot of tabs (Pedia, Commons page, Commons cat, Quote, Books, Tionary, Voyage, News, Versity, Data, etc), so we'll have to resort to the drop-down menu, which is even less visible. – Ypnypn (talk) 18:09, 24 April 2013 (UTC)
  • Can you cite some of those articles?--Micru (talk) 18:51, 24 April 2013 (UTC)
    • United States will have WP, 2 Commons, WQ, WB, WV, WVoy, WN, WD, Wikt, and WS. That's eleven. Cat can have all of them, plus Species.
      • I think that this can be fixed, if we like the general idea. We could make the layout of tabs "customizable" (to display only relevant projects, and put in a drop-down menu the others). Aubrey (talk) 21:29, 24 April 2013 (UTC)
        • The general idea isn't bad, but I don't see a practical way to make it actually work. The real problem is that these links require a lot of space, which there isn't a lot of at the top of the page. We could put them right under the title, but then the actual content of the page gets pushed down. Above the Article/Talk tabs would be cluttered. I'm open to solutions, but I haven't seen any yet. Regarding "customization" it creates problems if you're on a less relevant project. – Ypnypn (talk) 22:26, 24 April 2013 (UTC)
      • Is there a Wikivoyage page for Cat? ;) --NaBUru38 (talk) 22:32, 24 April 2013 (UTC)
        • There could be, such as traveling with cats (as pets). – Ypnypn (talk) 00:14, 25 April 2013 (UTC)
• Oppose This is the wrong approach in so many ways. Vector and Monobook are already waaay too overloaded with tabs as a navigational element. Currently, even if we reduced the number of tabs, this area of the site navigation is solely devoted to actions on a page (or links to an associated page in another namespace) on the current site. There is zero cross-site navigation, and confusing on-page action areas with interwiki links is a very bad idea for readers and editors alike. Even if it were not, the prioritization of elements is extremely unclear here: how would you include them, in what order, etc. The tabs mockup also does not include/seems to erase Talk and other essential current tabs. Steven Walling (WMF) • talk 04:30, 25 April 2013 (UTC)
• Oppose I don't think tabs are the right way to go about this. Legoktm (talk) 04:37, 25 April 2013 (UTC)
• Oppose As noted, having some tabs at the top direct the user to a completely different website with a different domain name has the potential to be very confusing. The idea with the current tab setup is that on the right hand side you have actions, and on the left hand side you have views to which those actions can be applied. Adding too many tabs, and adding tabs whose navigation behavior is completely different from the existing ones, will make the site more opaque. This type of approach may be viable in a completely different skin where reader mode and contributor mode are more clearly set apart.--Eloquence (talk) 08:01, 25 April 2013 (UTC)
  • Well, as said above to Dantman, "Read", "Edit" (or variant) and "View history" are something that applies to all of our wikis, so there wouldn't necessarily be an inconsistency if you don't move the Talk tab. Sure, this is quite harder to design, to avoid e.g. hiding talk pages or cluttering too much with more dropdowns. --Nemo 08:53, 25 April 2013 (UTC)
• Oppose--Steinsplitter (talk) 11:46, 25 April 2013 (UTC)
• Oppose like some others already said, bad design not practical--Stanzilla (talk) 11:53, 25 April 2013 (UTC)
• I agree with Erik. --MZMcBride (talk) 19:20, 25 April 2013 (UTC)
• Oppose - Interwiki/project links are not expected at this position in a standard wiki. And user on wikis outside the WMF would not expect them there. -- DerFussi 16:51, 27 April 2013 (UTC)
• strong oppose: First of all, I think four tabs is already cluttering. Next, what would happen with the other skins? Finally, I think that some users might be annoyed by this.--TheMillionRabbit 19:52, 27 April 2013 (UTC)
• Brutal oppose - if there's no transclusion we take people to another wiki (eww); if there IS, then they can't edit it. For instance, say there's a typo on a quote--how frustrating and anti-wiki that you can't update it there. Red Slash (talk) 00:27, 30 April 2013 (UTC)
• Oppose This interface is confusing. Mixing actions tabs like read, edit, discuss, etc. together with tabs that link to other projects in one area is confusing. Removing those actions from that area of the interface is confusing and makes participation harder. The image shows the Books tab as being for Wikisource, which is confusing for people when they unexpectedly end up at Wikisource rather than Wikibooks. Wikisource should use a different name, but not Source or Sources as that can be confused with Citation reference sources. I think a better option is to move all actions into a drop down menu next to the namespace tab and allow individual projects to define additional tabs and actions by editing a page in the MediaWiki: namespace like can already be done for the sidebar. The syntax of this page in the MediaWik: namespace could include some type of placeholders to be filled out by content on individual wiki pages using whatever method would have been used to fill out the project tabs. --darklama 14:49, 30 April 2013 (UTC)

Comments

• Comment I'm not sure how feasible is this solution, but I generally think that the current situation is not good for sister projects, because they are completely invisible. Any other solution is better for me. --Aubrey (talk) 08:13, 24 April 2013 (UTC)
• Comment Are the tabs history and edit on the talk page related to the article or the talk page? That is not a good idea to move the tabs talk to the right. — Ltrl G^☎ – 13:46, 24 April 2013 (UTC)

Option 2: Links on the sidebar

As deployed on the Italian Wikipedia

It would be another group of links as now happens with the language links. The Italian Wikisource is already using this system.

Comments

• Comment In my opinion this option doesn't give enough relevance to sister project pages, plus it clutters the interface.--Micru (talk) 01:33, 24 April 2013 (UTC)
• Comment Same as Micru. I think it's better than nothing, but doesn't solve the issue. --Aubrey (talk) 08:13, 24 April 2013 (UTC)
• Support Path of least resistance, can be implemented just like Wikidata interlanguage links (with per-page opt-out from standard system and/or locally added solutions). Of course, must be before the "Other languages" section and expanded by default. --Nemo 09:27, 24 April 2013 (UTC)
• Support --Snaevar (talk) 11:25, 24 April 2013 (UTC)
• Support This is the best solution so far, and also easy to implement. --Sannita - not just another it.wiki sysop 11:50, 24 April 2013 (UTC)
• Support, looks like the best of the three options suggested so far.--Ymblanter (talk) 12:06, 24 April 2013 (UTC)
• Comment -- I absolutely would take this option over doing nothing at all, but seriously - does anyone really think the sidebar is something that will still be around 2 or 3 years from now? Its a waste of screen-space in its current 'old man's Windows98 frames' as it is & that waste is prime real estate in the still expanding hand-held devices sector. -- George Orwell III (talk) 12:09, 24 April 2013 (UTC)
• Oppose -- normal users don't even notice the sidebar. Yuvipanda (talk) 13:41, 24 April 2013 (UTC)
• Oppose This kind of links should have a for better visibility. --Psychoslave (talk) 14:15, 24 April 2013 (UTC)
• Oppose The sidebar's already cluttered and not a great place to find things. Better than "no links at all" perhaps, but possibly worse than "semi-standard templates with links at the bottom of the page" which we have today. --brion (talk) 16:14, 24 April 2013 (UTC)
• Oppose This would be my next choice after tabs but I would prefer to avoid the sidebar. It is mostly technical tools and functional links as standard and not the place I would normally look for interproject links (nor would I expect a casual user to look there either). Wikivoyage uses the sidebar to keep the links out of the body of the text (which is intended to be just as usable when printed out), which is covered by the tab option as well. - AdamBMorgan (talk) 16:21, 24 April 2013 (UTC)
• Oppose No one notices the sidebar. It's not a problem for interlanguage links, which are sort of pointless, but sister projects are too important to hide. – Ypnypn (talk) 16:44, 24 April 2013 (UTC)
  • Support per Dartman below. – Ypnypn (talk) 00:43, 25 April 2013 (UTC)
• Oppose - sidebar's already cluttered, and may be on the way out; and there's no need to force a change of design on the projects to get the advantages of Wikidata. Only way I'd support this is if it's possible for a template to override it - so the links are then displayed if no-one's bothered to add an inter-project template to a page, but otherwise hidden. Can't see that happening though.Rd232 (talk) 16:51, 24 April 2013 (UTC)
  • I see no basis for the assertion that the sidebar is going to go away. There are no plans to ever get rid of the sidebar in Vector. Dantman (talk) 23:49, 24 April 2013 (UTC)
    • The sidebar has already gone in Mobile Wikipedia. Removing links from the main page content and moving them to the sidebar will make them invisible on mobile. (And while the sidebar is unlikely to be taken out of Vector, it's also unlikely that Vector will remain the default skin forever - remember Monobook used to be the default.) Rd232 (talk) 21:06, 25 April 2013 (UTC)
• Support above interwiki links, looks like the most suitable option.--Arnaugir (talk) 16:59, 24 April 2013 (UTC)
• Unenthusiastic support: It's cheap, but it's better than nothing. --NaBUru38 (talk) 22:13, 24 April 2013 (UTC)
• 

  Alternative mockup.
  Support This fits in with the defined behaviours of our skins. It's portable to all the skins Wikimedia uses. It can be implemented without hacking core. And as for those pessimistic about the sidebar why don't we use some actual design to make it more visible. Things in the sidebar going unnoticed has nothing to do with them being in the sidebar. It has do do with them being a blob of linked text that's not identifiable at a glance. After all the logo is part of the sidebar but you would never consider that unnoticed. To start with we could include icons for each of the sister projects beside the links. After doing that we could also try other things like wrapping the links in rounded boxes. Adding that would certainly make sister project links stand out. Dantman (talk) 00:35, 25 April 2013 (UTC)
  • Very good ideas. The image looks great. – Ypnypn (talk) 00:43, 25 April 2013 (UTC)
  • That's better but I think the sidebar is often used more by active editors than the average reader. Even the grey background colour de-emphasises the section and diverts the eye away and towards the body; if you aren't intentionally looking for it, the sidebar is likely to be ignored. (The exception to this is the interlanguage links section, which I admit are very similar in function and I have no data on how much they are used. The icons would help get a little more attention too.) As it stands, this would be my tertiary choice, after tabs and the dropdown by the title. - AdamBMorgan (talk) 11:55, 25 April 2013 (UTC)
• Support This area of the skin is already associated by users with interwiki navigation, so it's good place to experiment with ideas for linking to the sister projects. Steven Walling (WMF) • talk 04:32, 25 April 2013 (UTC)
• Support I'm a fan of the alternative mockup. Legoktm (talk) 04:39, 25 April 2013 (UTC)
• Support Alt. mock looks good to me as well; some of the favicons may need further polish in practice but it's a good place to start. One additional consideration is whether the focus should be on the projects names as in the mockup, or on the content they provide as in some other approaches. So you could have the Wikisource logo, but the text "Source texts", etc. The "Sister projects" + full project name is very good for promoting the jungle of different brands, but may actually lead to less traffic to the project because readers don't have any idea what the projects stand for. This decision could be made based on data, rather than making a priori assumptions.--Eloquence (talk) 08:06, 25 April 2013 (UTC)
  • Sure. That can be decided later with some data, very nice if the WMF is so kind as to provide it. I doubt anyone in this section objects to the logos (except that some projects don't have consistent logo and the mockup currently has the wrong one for Wiktionary). --Nemo 08:33, 25 April 2013 (UTC)
• Comment: They're still hidden in the bottom of the sidebar, but if I had to choose one of these it would be the alt. Prefer Options 5 and 1. PiRSquared17 (talk) 14:39, 25 April 2013 (UTC)
• I agree with Erik. --MZMcBride (talk) 19:24, 25 April 2013 (UTC)
• Support - Best position to place it and has been considered as very useful for six years now on Wikivoyage. -- DerFussi 16:53, 27 April 2013 (UTC)
• Strong support: put it above in the interlanguage links and it will be perfect. But use Wikidata anyway.--TheMillionRabbit 19:52, 27 April 2013 (UTC)
• Support I like the alternative mock-up, but it misses labels indicating what sister projects host, such as "Quotes" and "Media category."--Erasmo Barresi (talk) 16:33, 29 April 2013 (UTC)

• Excited support Far better than nothing; people who are interested will know where to find it and it won't get into anyone's way. Perfect. Red Slash (talk) 00:35, 30 April 2013 (UTC)
• Oppose There shouldn't be anything else depending on the presents of the sidebar. The sidebar hogs valuable screen space that should be used for wiki content. Somethings in the sidebar, like the toolbox should be next to the namespace tab in a drop down menu, and other things should be placed somewhere near the bottom of the page in maybe columns of three or four, like the language interwiki links. --darklama 15:01, 30 April 2013 (UTC)

Option 3: Keep current system

Another option is to keep the current system as it is.

Comments

• Oppose It is not a maintainable system, therefore I don't think it is a good option to keep it as it is.--Micru (talk) 01:33, 24 April 2013 (UTC)
• Oppose Sister projects are invisible. --Aubrey (talk) 08:14, 24 April 2013 (UTC)
• Oppose Absolutely impossible: we currently lack even such a basic feature as sitelinks to Commons on Wikidata. A simple and obviously needed feature like interwikis to Wikipedias on Commons is stuck (or will be implemented with even uglier workarounds than before) and the Wikidata team asks for an interface decision on them before moving a needle, see wikidata:Wikidata:Project_chat/Archive/2013/03#Sister projects links and data. --Nemo 09:27, 24 April 2013 (UTC)
• Oppose Otherwise we wouldn't be here discussing how to make this system better. --Sannita - not just another it.wiki sysop 11:50, 24 April 2013 (UTC)
• Oppose Agree w/Aubrey Sister projects are invisible the current way..... and I question the use of the term "system" to describe what is currently in place either way. -- George Orwell III (talk) 12:14, 24 April 2013 (UTC)
• Oppose Not satisfying. --Psychoslave (talk) 14:11, 24 April 2013 (UTC)
• Oppose per Aubrey and Nemo Yuvipanda (talk) 16:08, 24 April 2013 (UTC)
• Oppose Templates can be manually added as they are today, but this lacks consistency and isn't easy to automate. --brion (talk) 16:14, 24 April 2013 (UTC)
• Oppose There is no pattern across projects at the moment and even a lot of half-measures within projects. The en.wp approach of boxes at the bottom of the screen hides the links in the footer (where many users may never look; almost relegating them to a ghetto) and is often unappealing aesthetically (including potential whitespace issues, especially on shorter articles). - AdamBMorgan (talk) 16:21, 24 April 2013 (UTC)
• Oppose, I dislike it. DS (talk) 16:41, 24 April 2013 (UTC)
• Neutral - it's not that bad as is. - Ypnypn (talk) 16:43, 24 April 2013 (UTC)
• Oppose I think the system needs to be changed.--Arnaugir (talk) 17:00, 24 April 2013 (UTC)
• Oppose - The current system is a mess. Projects and editions aren't consistent, and links aren't prominent. --NaBUru38 (talk) 22:13, 24 April 2013 (UTC)
• Oppose per Aubrey and Nemo Tpt (talk) 07:17, 25 April 2013 (UTC)
• Oppose: the current system is too obsolete, when we have such a bunch of related projects. Soshial (talk) 19:35, 27 April 2013 (UTC)
• Oppose status quo is inconsistent and makes it too hard to find relevant content from other projects. --Tobias K. (talk) 19:43, 27 April 2013 (UTC)
• Oppose: nobody sees them.

Option 4: Current system + Wikidata

Each project can keep its current system, and re-develop existing templates to pull the relevant related-project links from Wikidata. This gives the advantage of using Wikidata, with the option to easily override (if for some reason the Wikidata setup doesn't always suit), and more generally allows each project its own design choices.

To be clear: the links would be kept on Wikidata. Thus, if the article Computer gains a page on Wikiquote, all the other projects would immediately gain a link - but their local templates would display it within their preferred layouts.

Comments

• Support as proposer. – Ypnypn (talk) 16:40, 24 April 2013 (UTC)
• Support (I've taken the liberty of rewriting the Option, as I was about to propose the same and duplication would be bad, hope first proposer doesn't mind). Rd232 (talk) 16:49, 24 April 2013 (UTC)
• Oppose It won't solve one of the main problems, which is Sister Project links being too hidden at the bottom of the page.--Micru (talk) 17:27, 24 April 2013 (UTC)
  • There's nothing to stop projects putting templates at the top of the page. Rd232 (talk) 18:22, 24 April 2013 (UTC)
    • That would require a separate option to vote. Besides there is not that much empty space left. The only place could be next to or embedded into the Table of Contents. I am not sure there is a good design that could fit in there, but you can try doing a mockup.--Micru (talk) 19:07, 24 April 2013 (UTC)
      • That would require a separate option to vote. - no it wouldn't. My point is that projects can do it if they want, not that we should force them to. I agree though that there doesn't seem any good design solution (that I can think of) for making the links more prominent near the top of pages. There's perhaps some potential for making them more prominent at the bottom of pages, with an automatic footer... Rd232 (talk) 19:18, 24 April 2013 (UTC)
• Comment this will probably be the default in the future, as we are going to ask the centralization of interprojects links anyway (because it's rational and useful for everyone). But as Micru states doesn't solve many of the issues, at least it won't if we don't find a good template that could be replicated in all projects. I understand option 1 it's fairly strong, and it requires a "paradigm shift" (Wikimedia projects seen as a "knowledge family"), but IMO that it's the direction. --Aubrey (talk) 21:23, 24 April 2013 (UTC)
• Support, of course this is the solution. One comment: remember that each subject doesn't just have main pages, but also categories, portals, wikiprojects and books. Wikidata item must include these links as well. --NaBUru38 (talk) 22:15, 24 April 2013 (UTC)
• Support It would relatively easy to do this, as far as I know, and it fits with how Wikidata treats interwiki language links currently. Steven Walling (WMF) • talk 04:37, 25 April 2013 (UTC)

  The Wikidata team doesn't seem to agree on this, ;) they asked an interface decision. I tend to think they're a more reliable source. --Nemo 08:23, 25 April 2013 (UTC)

• Oppose This is just a more sophisticated version of the existing problem. It doesn't unify or improve the visibility of any project (which, incidentally, includes links to Wikipedia from everywhere else). It still requires the manual addition of a template to the page (which will at best require a bot on each and every project inserting templates if none is there). - AdamBMorgan (talk) 11:27, 25 April 2013 (UTC)
• Support I can understand why Wikidata wants everything unified, but there's too much that might get destroyed if every project gets forced to file.--Stanzilla (talk) 07:58, 26 April 2013 (UTC)
• Oppose As the template would need to be transcluded on the page for the link to the sister project to appear.--Snaevar (talk) 18:50, 26 April 2013 (UTC)
• Comment I think this might be a move in the right direction in terms of being the least drastic of changes. I think some kind of interface would be required though to work because people aren't likely to goto Wikidata every time a new page is added that might be relevant for other projects, and people are likely to be confused if an edit link takes them to a different website. --darklama 15:15, 30 April 2013 (UTC)

Option 5: Dropdown next to title

Dropdown while open.

Interproject links in title dropdown (version 2)

Interproject links in title dropdown (version by NaBUru38)

Include a dropdown inside the page title that can be used to switch between sister wiki.

Comments

• SupportThis option can be done without any hacks to MediaWiki itself (the title markup can be modified from hooks). It's very visible. And having a switch in this location to move between wikis is not counter intuitive like overloading the namespace tabs are. Dantman (talk) 01:02, 25 April 2013 (UTC)

How will it look when closed? (It should be ovious but not intrusive.) – Ypnypn (talk) 01:34, 25 April 2013 (UTC)

• Support This would cover everything I would be looking for in terms of standardised interproject links. It's visible but discreet and can presumably be made standard across Wikimedia. I would rate my this as equal to the tab option in meeting my needs and probably slightly superior in terms of appearance and functionality. - AdamBMorgan (talk) 11:42, 25 April 2013 (UTC)
• Support I would like to see how the drop down menu would like when closed. If it is too visible it will be annoying, if it is too discrete interproject links will be again invisible.--Micru (talk) 13:12, 25 April 2013 (UTC)

I did an alternative mockup (see right).--Micru (talk) 14:03, 25 April 2013 (UTC)

• Support but collapsed by default. PiRSquared17 (talk) 14:30, 25 April 2013 (UTC)
• SupportThis would be a very interesting approach. However the design should also include the case where one would like to add several interlinks to a single project, like several wikibooks/wikiversities which teach advanced concepts used in the article. Also, from an accessibility point of view, you may also mockup a non-drop-down default case. --Psychoslave (talk) 14:33, 25 April 2013 (UTC)
• SupportThis is obvious, doesn't take up space, and doesn't interfere with other parts of the page. What more could you ask for? – Ypnypn (talk) 16:36, 25 April 2013 (UTC)
• Oppose Yes, this is much better than Option 1. But it has the same basic issues of (a) forcing all projects to use the same interface and (b) cluttering the interface at the top. There's also risk, if the clutter is made really minimally obtrusive, that the links will actually be less visible than down at the bottom of the page, where templates can take as much space as they want. Can someone mock up an alternative to Option 1 / Option 5 for the bottom of the page? Thanks. Rd232 (talk) 16:49, 25 April 2013 (UTC)
  • The whole point is to give sister projects more visibility, not to condemn them to the bottom for eternity...--Micru (talk) 19:05, 25 April 2013 (UTC)
• How about my version? It prevents long page titles to push the menu to the right. --NaBUru38 (talk) 18:32, 25 April 2013 (UTC)
  • The problem is that we have Wikipedia (name of project) next to Media (type of resource). They don't match. – Ypnypn (talk) 19:00, 25 April 2013 (UTC)
  • Another problem is that there is no indication that the interproject links are hidden there.--Micru (talk) 19:05, 25 April 2013 (UTC)
• Support Same spirit but better implementation than option 1. Aubrey (talk) 21:03, 25 April 2013 (UTC)
• Neutral Looks much better than option 1 (tabs). Would imho be the best solution if every project gets forced into the same interface in the end.--Stanzilla (talk) 08:02, 26 April 2013 (UTC)
• Support From all the options here, this one seems better. But do we have to add sister project page links manually for every article? Or it will be taken care of by wikidata? But the top space of source in the edit box should not look confusing/cluttered to new editors. The more template, syntax we use, the more confusing it will be for non-tekkie guys. -- ɑηsuмaη ^«T» 15:00, 27 April 2013 (UTC)
• Support I like this option: it doesn't overload the header ("Article", "Discussion" tabs) and look nice if they have icons of projects. Soshial (talk) 19:35, 27 April 2013 (UTC)
• Support: very nice. My second choice after option 2--TheMillionRabbit 19:52, 27 April 2013 (UTC)
• Oppose Hideous (to my eyes) and ugly (to my eyes) and cluttering. Far too intrusive for my tastes. Red Slash (talk) 00:32, 30 April 2013 (UTC)

Option 6: Complementary footer

This option is for a footer, which provides a standardised presentation of wikidata-based interproject links across the bottom of pages. The footer would be in addition to the existing template-based system, which would migrate to the new wikidata setup at its own pace (as in Option 4), and remain a complementary option, with projects and pages choosing whether to use templates in addition to the standard footer.

Interproject links are now usually found near the bottom of pages, together with external links, references and categories. There is a general sense that the bottom of the page is for "related items", for users to follow up who want more or related information. It therefore makes sense to put a standardised presentation of wikidata-based interproject links at the bottom of pages. This also avoids the clutter problem - the top of pages is already full of information. This also allows much greater scope for presentation of the links: more space, prettier designs, more visibility, and easier integration of Edit links. One possible design would be to echo Vector's tab design from the top of the page. Another advantage: a footer approach can more easily be adapted for the Mobile design whilst maintaining a certain consistency (some other options, like Sidebar placement, would require Mobile to do something completely different, since there is no Sidebar on Mobile). Consistency is surely one of the objectives of this standardisation.

This option provides a certain amount of flexibility when combined with the ideas of Option 4. Existing templates can be adapted to pull Wikidata properties into a page, and give particular prominence to sisterproject links that are particularly important on a page, or even to provide alternative links in some situations where the Wikidata setup linking that page with others on other projects doesn't provide a full solution.

Comments

• Support Noting that it could conceivably be combined with an unobtrusive version of Option 5, so that you have small and unobtrusive links at the top of the page, and larger and more visible links at the bottom. Rd232 (talk) 11:53, 26 April 2013 (UTC)

Could you make a mockup? Just to understand better what you mean. Aubrey (talk) 13:37, 26 April 2013 (UTC)

I'm not very good at that, and it can be done in a wide variety of ways; I'm more interested in the principle. Others are welcome to provide mockups though. Rd232 (talk) 13:53, 26 April 2013 (UTC)

...

Option 7: Use content to represent the sister sites

Design to represent a Wikidata concept as a way to unify information from different Wikimedia projects.

Users are more likely to explore sister sites if they have an idea of what to expect. Making the expected content such as images, quotes and books to surface may help. We can provide an icon for the user to access "additional content". Once the user clicks on the icon, a summary card with aggregated information in a visual manner. Users can access the sister sites through the information on the card. I made a mockup to illustrate the idea, but further though will be required to better determine the icon to use, the location and the visual information of the card.

These cards are potentially linkable so that external sites can also link to a Wikidata concept in the same way.

Comments

• Nice idea, good mockup, but I fear it may require quite a bit of extra work compared to some of the other options. But this is much more appealing and forward-looking than some of the other options, and I'd be happy to see it explored further. Rd232 (talk) 16:01, 30 April 2013 (UTC)
• I agree with Rd232. Making sister projects content more prominent in Wikipedia it's probably the Holy Grail :-), but it's a huge work. We should work a lot on transclusion, and probably have the WMF staff dedicated some time to this idea. We culd transclude quotes from Wikiquote, sections of texts from Wikisource, galleries from Commons. I fear that it's paradigm shift that won't happen soon. --Aubrey (talk) 10:36, 1 May 2013 (UTC)

Option 8:

...

Comments

...

Issues

Layout

One key aspect of the discussion is the layout. The interface must include among other aspects:

• It must be simple and clean.
• It must encourage users to visit the interwiki links.
• It must be adaptable to the different versions: web, mobile, desktop (iOS, Win8 and Android apps), etc.

What do you think about the layout? --NaBUru38 (talk) 22:21, 24 April 2013 (UTC)

Comments

Mobile is irrelevant to the layouts being discussed. Mobile devices are served by MobileFrontend which will always do links like these in a completely different way than will be done in normal skins. Dantman (talk) 23:53, 24 April 2013 (UTC)

Apps are irrelevant too. This really is just 'web'. Yuvipanda (talk) 04:28, 25 April 2013 (UTC)

Another (so far ignored) point is that some articles will have a dozen such links, others will have none. We need to find a method that could work well with any number of links. Ypnypn (talk) 18:12, 26 April 2013 (UTC)

Non-mainspace links

As I mentioned above, each subject (like w:en:Technology) doesn't just have main pages, but also portals (w:en:Portal:Technology), wikiprojects (w:en:Wikipedia:WikiProject Technology) and books (w:en:Book:Technology), plus its respective main categories. I believe that these should be included in the discussion as well. What should we do about them? --NaBUru38 (talk) 22:25, 24 April 2013 (UTC)

Comments

• None of the current methods would allow for this. What might is a navbox-like template. – Ypnypn (talk) 22:29, 24 April 2013 (UTC)
• Categories depend on the skin. Portals and stuff are internal navigational links which don't have a standard or pseudo-standard "storage" system anywhere, so it's currently impossible to handle them centrally and it's also unlikely they'd be added to Wikidata. Additionally, I don't think it's a good idea to try and redesign the whole navigational templates and "see also" etc. etc. all the projects have, all at the same time... You'd never come to any conclusion, and that's more typically "content" than interface. --Nemo 08:39, 25 April 2013 (UTC)
• See my Option 6 on keeping some local flexibility. Rd232 (talk) 12:11, 26 April 2013 (UTC)

Customization

Because of the variety of situations, and to prevent revolts along the projects and editions, it's reasonable to think that there will be some sort of level of customization with interwiki links. Depending on which options are chosen, what should be customizable? Which interwikis appear, their order, their font size? SHould the customization be per project, per edition, per page? --NaBUru38 (talk) 22:35, 24 April 2013 (UTC)

Comments

Customization would be nice, but I imagine it would be technically difficult (or at least burdensome), and also defeat a large part of the "consistency across projects" objective. See my Option 6 which frames the standardised links as additional to whatever the project or page wants to do in its templates (eg to highlight key links or provide alternative links that wouldn't go into the Wikidata links for the page). Rd232 (talk) 12:16, 26 April 2013 (UTC)

...

Misleading RFC

"Sidebar" is currently a popular option. Apparent result: no interproject links on mobile devices (the default mobile skin has no sidebar)??

It seems to me that this RFC is misleading and badly designed. The stated objective is to ask the communities for their opinion on proposed interfaces that would allow storing the interproject links in a central location, such as Wikidata.

1. This stated objective bears no relation to the "current situation" background description, or to the initial proposals, which are all about the design of interproject links. Not a one of the initial proposals (Options 1 to 3) actually requires Wikidata to exist at all: those design choices could just as well be imposed on all projects without it.
2. There is no clarification of how interproject links will be constructed and maintained. I gather that it'll be somewhat similar to interwiki links, so for instance Wikipedia article X has as an associated Statement a Commons category Y (Property:P373). If this is how it'll be, why has no-one bothered explaining it (or linking to an explanation elsewhere, if one exists)?

But most fundamentally, if my understanding of 2. is correct, then there is no need whatever to have an RFC. Transition to interproject links being stored on Wikidata would happen very easily, with existing projects adapting their templates to pull the relevant wikidata property for that page, and bots transitioning existing interproject links to Wikidata just as they did for interwiki links. (The only awkwardness would be having to build in an edit link to Wikidata - but that's a wider issue to using Wikidata.)

As is abundantly evident from so many of the responses, there is actually a violently different objective being pursued here, which is not to centralise interproject links in Wikidata, but to use the centralisation of project links in Wikidata as an excuse to impose a redesign of interproject links on all projects, making them much more prominent near the top of the page. Some of the things apparently not considered (certainly not evidenced) include

1. whether the result would be actually any use to users (when they come to a page, are they desperate to leave, and need to be helped to do so before scrolling down... or is looking for related resources something that they will normally do after scrolling down?)
2. whether one size fits all across all situations on all projects and devices (and no, you can't ignore mobile)
   • and if not, how project opt-outs or exceptions within opted-in projects would be handled
3. how the inevitable enormous outrage from the large proportion of users who won't comment in the RFC will be handled
4. how a transition would actually work (bots removing existing templates? edit-warring with users re-inserting them??)

This looks like a mess, and a disaster in the making. Maybe someone can explain to me how I'm wrong. Rd232 (talk) 21:43, 25 April 2013 (UTC)

Given the page's title and content, it seems fairly clear that this is about the look/design, not about the implementation details. :-) I agree that the current page lead ("This RFC has the aim to ask the communities for their opinion on proposed interfaces that would allow storing the interproject links in a central location, such as Wikidata.") is a little misleading, but I wouldn't say this RFC as a whole is misleading. That's awfully harsh language. This page seems to have been started in—and engaged with in—good faith.

Regarding your actual objection(s):

"whether the result would be actually any use to users (when they come to a page, are they desperate to leave, and need to be helped to do so before scrolling down... or is looking for related resources something that they will normally do after scrolling down?)"

Part of this is to better advertise the sister projects. An "Objectives" section on this page might be a good idea.

"whether one size fits all across all situations on all projects and devices (and no, you can't ignore mobile)"

Mobile will handle itself. It already excludes and includes features as it pleases, don't worry about mobile. This is about the browser version of the Wikimedia wikis, which is fairly consistent (with the exception of a few sites that use still use Monobook, but even that's fairly similar in appearance). If anything, perhaps there should be a bit more anger at the fact that every site uses Vector and you weren't consulted. Oh well.

"how the inevitable enormous outrage from the large proportion of users who won't comment in the RFC will be handled"

This of course depends on which design is chosen. A lot of the proposed designs most users wouldn't notice at all. ;-) A few look like they'd be horribly obnoxious and won't ever be chosen. Don't worry so much.

"how a transition would actually work (bots removing existing templates? edit-warring with users re-inserting them??)"

Again, this is an implementation detail, when this page is pretty clearly focused on design. The final implementation (if there ever is one and "final" really has no meaning) may use wiki templates. It may use Wikidata. It may use templates and then transition to templates. Who knows. --MZMcBride (talk) 05:29, 26 April 2013 (UTC)

Well, thanks for your response. I'm not really convinced by it. Most especially I'm not convinced by the Mobile will handle itself. attitude. Mobile isn't magic, it's an alternative way of displaying page content. If the interproject links are removed from the page content (which mobile displays) and moved to the sidebar or some other interface element mobile doesn't display, then interproject links will no longer be visible on mobile. If the objective is to make interproject links more prominent, that seems like something that ought to be taken into account! Also, your comparison with Vector is interesting. Any user can opt out of Vector (I did for a while, but eventually switched). How can any user opt out of these proposals? Rd232 (talk) 09:22, 26 April 2013 (UTC)

PS Sure, I'm not saying there's bad faith here, even if my late-night grumpy posting may seem to have implied it. It seems more of an opportunistic "Wikidata is happening. Let's redesign, and finally give sister projects the prominence they deserve!" sort of thing. At least part of my irritation is the firm belief that if this was advertised on major Wikipedias (sitenotice/centralnotice), you'd be just overrun with people falling over themselves to say "no, don't force any change in the interface on all projects", and in the stampede you'd be lucky if people bothered to add "(unless the design is just fantastically brilliant)". Rd232 (talk) 09:30, 26 April 2013 (UTC)

Hi Rd232. I am one of the partners of Micru (the proponent of the RfC) in a grant project focusing on Wikisource. That means: this Rfc has been proposed within the task concerning that project. We did not wrote that explicitly (to focus on the proposal here, as this RfC is fairly indipendent as it is), but maybe it's an important disclosure.

Please bear with me in assuming good faith here. We are not stupid enough to think that a RfC alone can force anything in Wikimedia projects. We are proposing a bold paradigm shift, conscious that some people would love the idea and some would hate it. We are asking for comments and feedbacks, in a Meta page (so directed on internal, internationals, very skilled wiki users) to gather data and opinions. We proposed a tab interface, that was very bold and with few chances of being accepted. It was an idea, and I'm glad that Option 5 goes in that direction, but with a more brilliant design.

As for the phrasing of the RfC, we may be made some mistake, but always in good faith. Centralising interprojects links in Wikidata it's an option, not a reality, but it's also the necessary condition of the redesign we are proposing here. So this RfC, if you want, is assuming a change presenting a redesign proposal. We can surely make that more clear, but I really don't see how this can be seen as "misleading".

As for "Wikidata is happening. Let's redesign, and finally give sister projects the prominence they deserve!", I don't see how this attitude can be a problem. We now have Wikidata, born to centralize Wikipedia things". We have the same issue for interprojects links as we had for interlinks. Centralising those could be a low-hanging fruit for Wikidata and a huge step forward integration of Wikimedia projects.

We are proposing a redesign interface to make those links visible. We are proposing this here, in Meta, and I think there'll be a long road for any proposal to be really implemented. We can't use the sitenotice to ask all Wikipedia users around the world. We'll see how this RfC goes, maybe one day we will :-)

I hope I answered some of your questions. Cheers, Aubrey (talk) 10:58, 26 April 2013 (UTC)

OK, thanks. Perhaps I should have avoided the word "misleading", which is often read as "intentionally misleading", which I didn't mean. And of course there's nothing wrong with wanting to give sister projects more prominence, as long as that desire takes into account what's useful to users and isn't just satisfying contributors. Anyway, the problem is that the RFC has gone straight into "how should a standardised interface look", and totally bypassed all the issues around transitioning to an interface standardised across all projects. It seems to have been assumed that it would work just as smoothly as the interwiki links transition to Wikidata, and it should be clear that it wouldn't be anything like that. Rd232 (talk) 11:35, 26 April 2013 (UTC)

I've tried to organise these thoughts into a new Option 6 that takes these various issues into account. Rd232 (talk) 12:17, 26 April 2013 (UTC)

Hi Rd232, just to add a bit on what Aubrey already said. Yes, there are two different discussions: one debate is if it is wanted to give more prominence to sister projects, and the other debate is how. IMHO it was important to ask first about the design options before bringing the other subject to the public light. The reason is that, as we are realizing, there are issues that we were not taking into account (as the one you pointed out: mobile), or that there might be other unknown impediments that would render the debate useless.

I agree with you that this is not the kind of rfc to advertise as a sitenotice, it is more for internal attention. The public debate will have to be prepared in advance in different terms. If you had time, would you like to help us to shape how we bring the topic into attention?--Micru (talk) 13:43, 26 April 2013 (UTC)

I think my Option 6 now covers most of my points. I think people arguing for prominence at the top of the page should provide some evidence that this is what users actually want and/or need. Structurally, it just doesn't make sense to me. In terms of developing the topic - well it's a bit difficult from here. I would have started with a discussion about objectives, and about technical issues of storing interproject links in Wikidata, and left redesign ideas until after that was clarified - it seems a bit putting the cart before the horse. PS Are you aware of en:Wikipedia:Requests_for_comment/Wikidata_Phase_2, which may well cover using Wikidata for interproject links? Rd232 (talk) 13:58, 26 April 2013 (UTC)

Well, I think that any conversation about technical issues of storing interproject links in Wikidata should be lead in Wikidata, not here. Regarding WD's Phase 2, yes, I am very aware of that, however it is a different matter. For Commons you can have a link for all Wikipedias, in other projects not so, because there is a link for each language version, so it is not possible to use the capabilities deployed in phase 2 for the interproject linking problem. Agreed that the prominence of sister projects needs a different discussion.--Micru (talk) 12:26, 29 April 2013 (UTC)

Comments

• Support Killiondude (talk) 05:19, 26 April 2013 (UTC)

  What are you supporting? PiRSquared17 (talk) 19:02, 26 April 2013 (UTC)

  Every other "Comments" section had votes. I felt like this section was lacking without. Killiondude (talk) 00:57, 27 April 2013 (UTC)

  Support ;) Rd232 (talk) 10:06, 27 April 2013 (UTC)

...