Last modified: 2014-11-17 10:34:49 UTC
We need interproject links badly. I explained what I was thinking about here : http://en.wikipedia.org/wiki/Wikipedia%3ARecipes_proposal#.5BWikitech-l.5D_Projects_linking Any time, a tool bar of interproject should be found, possibly some icons. When one clicks, he goes to the same page in another project. For example, I mentionned the Fugu, with a short description in wiktionary; the biological and social description in Wikipedia, the recipe in wikibooks, and possibly a whole set of images/sounds... in wikisources.
I think this feature is a must for all projects.
Please get this done as soon as possible! It seems to be the only compromise able to stop the largest fight we've had on Dutch Wikipedia since... Well, I don't think we had any larger one in fact.
Created attachment 124 [details] GUI mock-up of interproject (sister project) links This is a simple GUI mock-up of how I intend to implement this.
Please don't change the bug assignment without adding wikibugs-l to the CC list, as that screws up the automated reporting tools (mailing list, IRC notification).
One sensible comment on nl:wikipedia was about the positioning of the interproject links. As the interlanguage links can number potentially more than 20/30 it would be sensible to have the interproject links above the interlanguage links. Thanks, GerardM
The sidebar gets crowded, esp. for pages with many interlanguage links. The likelihood that someone uses an interproject link is higher than that someone uses an interlanguage link. So put interproject links below the article instead of in the sidebar.
One problem that needs considering is how the syntax for these would work: the obvious choice would be to have [[Wiktionary:Foo]] behave "out of line" analagously to [[fr:Foo]], with [[:Wiktionary:Foo]] to over-ride. Unfortunately, that messes with the existing ability to create *inline* inter-project links, and doing the leading colon thing the other way round would be confusing. One alternative to a completely new syntax would be to put this off until we've split "metadata" (such as the existing out-of-line language and category links) into a seperate store. We don't need to actually be doing anything different with the text (although it's the first step toward things like centralising inter-language links), just automatically moving inter-language and category links from the article text at the "pre-save transform" stage. The point being, that we could then have a "metadata" box (not necesarily called that) that displays these, and any inter-project links entered there would be unambiguously "out of line".
You could have the software automatically put the interproject links to the same article on the bar, and the article. [[:WikiBooks:C]], for example, would take it off the article. (We're going to have to do this if we dont wanna break a lot of pages.
(In reply to comment #8) > [[:WikiBooks:C]], for example, would take it off the article. I'm not 100% sure what you mean, but my thinking is that using the "leading colon escape" won't be enough: * doing it the same as we do now for languages and categories ("[[Wikt:Foo]]" goes to the sidebar/wherever, but "[[:Wikt:Foo]]" displays 'in situ') will break existing usage. * doing it the other way round ("[[Wikt:Foo]]" stays 'in situ', but "[[:Wikt:Foo]]" goes to the sidebar/wherever) would break the generality of "add a leading colon to stop the link behaving specially" - it would be especially confusing with complex links like "[[wikt:en:Foo]]", where someone might well think they needed to put "[[:wikt:en:Foo]]" (they don't need to, but it is logical). So, in my opinion, we need some completely new way of specifying "this article has an equivalent on a sister project, called..."
Yeah. We're either going to have to break a pattern or all of the links suddently dissapear. We should not piggyback this on the current link system, i.e. use something like {:wikt:foo:} for transproject sidebar links or something.
There would of course be no need for an explicit link syntax. We require them for interlanguage links because the pages have different titles. Interproject SisterSites-style links would be automagic if implemented.
We might need an explicit link syntax for several things. For example, we would want to link [[w:C plus plus]] to [[b:Programming:C plus plus]]. Else, how could we link the two together?
I think we should keep the convention of no colon goes in the bar, colon means in-place link. To fix current links, a script will have to be run at the software conversion time that updates all the links to use the colon notation.
*** Bug 4208 has been marked as a duplicate of this bug. ***
Brion: Besides pages with different titles in the same language, we will also have situation where interproject links point to a different language, particularly in Commons, which is very English-centric. It may also be that we have a project in a minor language but a sister project only exists in English (for example, Wikinews exists in far fewer languages than other Wikimedia projects). Sometimes, it may be desirable to link between them, especially if the minor and the major language are related. Because language does play a role, I think this should probably go hand in hand with a redesign of the interlanguage link tables, which could be moved to a central database that can be edited from each wiki. See http://meta.wikimedia.org/wiki/A_new_look_at_the_interwiki_link on Meta, and the associated talk page, for some thoughts. This would be a more flexible system, where we could show interlanguage and interproject links based on the user's language preferences.
Just for your information: On the German Wiktionary we are using a JavaScript workaround now! Have a look on [[wikt:de:MediaWiki:Monobook.js]] and [[wikt:de:Wiktionary:Schwesterprojekte]] to see how it works.
*** Bug 5396 has been marked as a duplicate of this bug. ***
Portuguese Wikipedia too implementation sister projects in Javascript based on German Wiktionary. See [[w:pt:Template:Correlatos]].
(In reply to comment #18) > Portuguese Wikipedia too implementation sister projects in Javascript based on > German Wiktionary. See [[w:pt:Template:Correlatos]]. should read [[pt:Template:Correlatos]]
(In reply to comment #19) > (In reply to comment #18) > > Portuguese Wikipedia too implementation sister projects in Javascript based on > > German Wiktionary. See [[w:pt:Template:Correlatos]]. > > should read [[pt:Template:Correlatos]] Correct page is [[pt:Wikipedia:Vários projectos correlatos]]
*** Bug 6347 has been marked as a duplicate of this bug. ***
*** Bug 6501 has been marked as a duplicate of this bug. ***
*** Bug 7323 has been marked as a duplicate of this bug. ***
Get it done quickly. This bug is here now for 2 years and we still use this worthles system.
*** Bug 7428 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > Brion: Besides pages with different titles in the same language, we will also > have situation where interproject links point to a different language, > particularly in Commons, which is very English-centric. It may also be that we > have a project in a minor language but a sister project only exists in English > (for example, Wikinews exists in far fewer languages than other Wikimedia > projects). Sometimes, it may be desirable to link between them, especially if > the minor and the major language are related. > > Because language does play a role, I think this should probably go hand in hand > with a redesign of the interlanguage link tables, which could be moved to a > central database that can be edited from each wiki. See > http://meta.wikimedia.org/wiki/A_new_look_at_the_interwiki_link on Meta, and the > associated talk page, for some thoughts. This would be a more flexible system, > where we could show interlanguage and interproject links based on the user's > language preferences. Has changes to the interlanguage code made this more reasonable/feasible since this comment was posted?
No significant change has been made to the system.
*** Bug 195 has been marked as a duplicate of this bug. ***
I'm getting excited just thinking about the /possibility/ of this bug being addressed.
Dear boys and girls, instead of *ignoring* this feature request *for years*/forever, you could do this very *quick* and *easy* fix: 1. Add ~apparent *interlang links* [[wikt_iw:]], [[b_iw:]] etc. either with destination to the appropriate project or to enwiki (if it should not be possible to link to an other domain)! 2. Give those links the appropriate project names in *Names.php*! Interproject links will work like this then, without any further changes: [[wikt_iw:wikt: Isn't that easy?]] [[b iw:b: Yes, I think so!]] <!-- note: additional "wikt:", "b:" etc. only necessary then if linking to other domain not possible --> [[n_iw:n:en: Hmm ;-)]] <!-- n:fr: --> If you do not want to create another interlang links for this, misuse *existing ones of closed langs* like [[tokipona:]] and [[tlh:]]! Just change names in Names.php. And SysOps can change content of *[[MediaWiki:Otherlanguages]]* from "(Other) Languages" to "(Sister/Other) Projects / (Other) Languages" then!
(In reply to comment #30) > 2. Give those links the appropriate project names in *Names.php*! Those don't belong there.
Why can't we just do [[q:simple:Foo]]?
Btw I like the way this in done in English Wikipedia, where more information about the target is given than just a project name.
Niklas Laxström <niklas.laxstrom@gmail.com> changed: > What |Removed |Added > ---------------------------------------------------------------------------- > Priority|Highest |Low I have reverted the above change in priority.
> I have reverted the above change in priority. Unless you are a developer, don't touch them. This is not a wiki.
I agree, i think that this merits a spot above the language box.
(In reply to comment #33) > Btw I like the way this in done in English Wikipedia, where more information > about the target is given than just a project name. it.wiki's [[:it:Template:Interprogetto]] offers lots of features to add links, titles and descriptions. Way more than in en.wiki (which is quite crappy). It's used in 170,000 pages, plus every Italian language sisterproject.
About the prefix to be used, wouldn't it be simpler to just prefix the project interwiki with the language code ([[en:wikt:Targetpage]] to add an interwiki from English Wikipedia to English Wiktionary), rather than set up new types of prefixes or breaking the colon-means-in-place-link convention? Currently a different_language_code:project_interwiki:target creates an interlanguage link that actually leads to a different project, and same_language_code:project_interwiki:target doesn't create a link at all. Note: English Wiktionary, which uses a javascript workaround for interproject links, has many entries with interproject links to other languages. If interproject links are going to be possible, they should really allow linking to other projects in other languages, too.
Created attachment 8783 [details] Possible implementation of interproject links Apparently this bug is waiting for years and no-one implemented it yet (it is not that difficult). This bug has even the highest number of votes. Anyway, I made a patch that adds a configuration variable $wgInterProjectLinks with 'prefix' => 'Project name'. Links with [[prefix:Title|Text]] will show up in the sidebar as "Text" and links with [[prefix:Title]] will show up as "Project name". The links are still shown inline in the wikitext (so it doesn't break everything). Links with [[:prefix:Title]] (extra colon) are not shown in the sidebar. The position in the sidebar can be changed with * OTHERPROJECTS This patch implements it for vector and monobook. If it's OK, I can add it to the other skins as well (and possibly commit it to SVN).
*clap clap* This obviously covers only "local" interwikis, doesn't it? (In reply to comment #39) > Links with [[prefix:Title|Text]] will show up > in the sidebar as "Text" and links with [[prefix:Title]] will show up as > "Project name". The links are still shown inline in the wikitext (so it doesn't > break everything). Links with [[:prefix:Title]] (extra colon) are not shown in > the sidebar. What happens if there are multiple links to the same project? I'm not sure it's wise to show "Text" in the sidebar, it could be half a sentence. For both points, it's probably better to adopt the usual implementation of interproject templates, which AFAIK show only the first link to each project and show only the name of the project in the sidebar, leaving the details to the page body. In any case, this will probably require some fixing of links which will need the extra colon, which will acquire a new meaning (although consistent with its current one). This shouldn't be a disaster, though, because inline interwikis to random pages (no directly equivalent to the page they're in) are deprecated on most projects, AFAIK; probably, it would be useful to ignore interwikis in references, which could be dozens on a single page and are usually considered the right way to link whatever page on another project (like any website).
At Wikibooks there are interproject links to Wikipedia galore. While it's true that we discourage them in order to have all content defined in-text, they are still extensively used. And there are many [[w:|Wikipedia]] links simply to link to Wikipedia. And Wikibooks is not a dictionary, so words may be linked to Wiktionary. Wikiversity was split off, so some concepts may be linked to there. Interproject links are not used at Wikibooks in a one-to-one ratio with the pages and do not match local page content to the equivalent at the other project. The suggested implementation would be a disaster at Wikibooks. Only Wikipedia takes the hardcore stance that "outside" links must all be in an external links section and isolates itself from the other projects. Unless you run a bot to replace [[w:blah|blah]] with [[:w:blah|blah]] on every page of every wiki, the sidebar links would be completely incorrect. At least the suggested implementation wouldn't make them disappear like current interlanguage links, but that's of little consolation.
(In reply to comment #41) > Interproject links are not used at Wikibooks in a one-to-one ratio with the > pages and do not match local page content to the equivalent at the other > project. The suggested implementation would be a disaster at Wikibooks. Only > Wikipedia takes the hardcore stance that "outside" links must all be in an > external links section and isolates itself from the other projects. This doesn't apply to all languages. For instance, the same rule is quite consistently applied on all projects in Italian since 2005-2006 AFAIK (and it's the same in several other languages). I agree that the problem must be considered, though. Could we have some statistics on how many sisterproject interwikis we have on pages?
(In reply to comment #42) > This doesn't apply to all languages. For instance, the same rule is quite > consistently applied on all projects in Italian since 2005-2006 AFAIK (and it's > the same in several other languages). I agree that the problem must be > considered, though. Could we have some statistics on how many sisterproject > interwikis we have on pages? Maybe what you're looking for: Wikipedia: http://stats.wikimedia.org/EN/TablesDatabaseWikiLinks.htm Wikibooks: http://stats.wikimedia.org/wikibooks/EN/TablesDatabaseWikiLinks.htm Wikinews: http://stats.wikimedia.org/wikinews/EN/TablesDatabaseWikiLinks.htm Wikiquote: http://stats.wikimedia.org/wikiquote/EN/TablesDatabaseWikiLinks.htm Wikisource: http://stats.wikimedia.org/wikisource/EN/TablesDatabaseWikiLinks.htm Wikiversity: http://stats.wikimedia.org/wikiversity/EN/TablesDatabaseWikiLinks.htm Wiktionary: http://stats.wikimedia.org/wiktionary/EN/TablesDatabaseWikiLinks.htm
(In reply to comment #43) > (In reply to comment #42) > > Could we have some statistics on how many sisterproject > > interwikis we have on pages? > > Maybe what you're looking for No. I know those statistics, they're only interlanguage wikilinks ("regular" interwikis); and anyway, they just show the total, while we'd rather need the number of pages with interwikis to sisterprojects, average and standard deviation of the number of them on those pages. This way we could see how many projects and how many pages on them would experience the problem you described.
(In reply to comment #44) > No. I know those statistics, they're only interlanguage wikilinks ("regular" > interwikis); and anyway, they just show the total, while we'd rather need the > number of pages with interwikis to sisterprojects, average and standard > deviation of the number of them on those pages. This way we could see how many > projects and how many pages on them would experience the problem you described. I'll get right on that in order to prove my concern is valid.
(In reply to comment #40) > This obviously covers only "local" interwikis, doesn't it? It covers interwikis in $wgInterProjectLinks, no matter if they are local or global (although I'm not sure what you mean by "local"). > What happens if there are multiple links to the same project? They are all shown. > I'm not sure it's wise to show "Text" in the sidebar, it could be half a sentence. I thought it would be useful to specify a text other than the default project name, e.g. [[n:Title|View news reports about this event]] But it's easy to remove this feature from the proposed patch. (In reply to comment #41) > The suggested implementation would be a disaster at Wikibooks. If my implementation is chosen, it can be specified opt-in per-project through $wgInterProjectLinks.
(In reply to comment #46) > (In reply to comment #40) > > This obviously covers only "local" interwikis, doesn't it? > > It covers interwikis in $wgInterProjectLinks, no matter if they are local or > global (although I'm not sure what you mean by "local"). iw_local http://www.mediawiki.org/wiki/Manual:Interwiki#Field_documentation To see it in action: [[MeatBall:]] doesn't work ([[mw:]] neither but it's probably an error), you surely don't want to add such links to sidebar. > > What happens if there are multiple links to the same project? > They are all shown. > > > I'm not sure it's wise to show "Text" in the sidebar, it could be half a > sentence. > I thought it would be useful to specify a text other than the default project > name, e.g. [[n:Title|View news reports about this event]] > But it's easy to remove this feature from the proposed patch. Probably better. > (In reply to comment #41) > > The suggested implementation would be a disaster at Wikibooks. > If my implementation is chosen, it can be specified opt-in per-project through > $wgInterProjectLinks. That would be another bug but I'd hope this to be at most opt-out for Wikimedia wikis; in other words, we should find a solution which works for most people. More realistically, though, shouldn't the configuration be true by default in MediaWiki? You still can control it by defining which interwikis are local, if my proposal above is adopted.
(In reply to comment #47) > iw_local http://www.mediawiki.org/wiki/Manual:Interwiki#Field_documentation > To see it in action: [[MeatBall:]] doesn't work ([[mw:]] neither but it's > probably an error), you surely don't want to add such links to sidebar. Uh, looks like bugzilla got smarter. I meant http://en.wikipedia.org/wiki/MeatBall: , let's say [[MeatBall:Whatever]].
Take a look at Swedish Wikipedia, http://sv.wikipedia.org/wiki/Portal:Huvudsida, in the left panel under the heading "På andra projekt". Or an individual article: http://sv.wikipedia.org/wiki/Ivar_Kreuger.
I raised a request for this at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&oldid=468244763#Allow_interlanguage_links_to_Commons_for_non-article_space_pages, which has gained support from two other users (so far). Optimist on the run (formerly Tivedshambo)
For the moment, both interproject links [[wikt:…]] and [[:wikt:…]] are in-place-links. But for interlanguage links, [[en:…]] is an interwiki and [[:en:…]] is an in-place-linkt. It should be easier if it was the same for the interproject links as for the interlanguage links. Does it helps if bots change all the in-place-links from [[wkt:…]] to [[:wkt:…]] (and for all the interproject links) ? Then, the [[wkt:…]] links could be used for interproject links in the left panel (like the interlanguage links). Shall I make a request for bots on each wikipedia project ? Or can it be done by a bot on all the projects ?
(In reply to comment #51) > Shall I make a request for bots on each wikipedia project ? Or can it be done > by a bot on all the projects ? I'd wait until the feature is in fact part of MediaWiki. Changing links when it's not (yet) needed seems a bit useless.
(In reply to comment #52) > I'd wait until the feature is in fact part of MediaWiki. Changing links when > it's not (yet) needed seems a bit useless. Is it ready now ? When will it be in fact part of Mediawiki ? I think that changes can be done before, to prevent misuses of the syntax. If we change the in-place-links before, users can adapt to the new in-place-links and will not be surprised by the new interproject links (when ready and part of Mediawiki), and I think this is not a bit useless.
Hi Robin, thank you for the patch! As you may already know, MediaWiki is currently revamping its PHP-based parser into a Node.js-based "Parsoid" component, to support the rich-text Visual Editor project: https://www.mediawiki.org/wiki/Parsoid https://www.mediawiki.org/wiki/Visual_editor Folks interested in enhancing the parser's capabilities are very much welcome to join the Parsoid project, and contribute patches in form of Git branches: https://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch Compared to .diff attachments in Bugzilla tickets, Git branches makes it much easier for us to review, refine and merge features. Each change set has a distinct URL generated by the "git review" tool, which can be referenced by pasting its gerrit.wikimedia.org URL as a Bugzilla comment. Please feel free to ask on irc.freenode.net #wikimedia-dev if you run into any issues with the patch process. Thank you!
(In reply to comment #54) I just thought I'd let you know that your message might have come across as slightly patronizing. Robin is an experienced MediaWiki developer, but even if he wasn't, such boilerplate(-like?) messages are seldom a useful way to communicate with volunteers anyway. Please take this as constructive criticism only :)
Thanks Waldir! No offense taken, and apologies for the incongruous tone -- English is definitely not my forte, and I'm still striving to improve my use of this language. :-) For context, I've only recently joined the Parsoid/VE projects as a volunteer, and this boilerplate text was sent to all parser bugs with patches attached, at the behest of Sumana, in an effort to encourage people signing up to Gerrit, and hopefully bring their patches to Parsoid where it makes sense. I've tried to triage them and respond only to bugs that seems pertinent, but as a newcomer to this community, there's bound to be some false positives as well as needless duplication. Again, my sincere apologies for the (semi-)spamming -- it won't happen again anytime soon.
(In reply to comment #56) Au: I'm pleased people are looking at these bugs with patches. One thing you might look at is how long the patch has been awaiting review: this one, for example, was written for MW 1.17; the current version is 1.20.alpha. Thank you, and welcome to Bugzilla!
(In reply to comment #57) > Au: I'm pleased people are looking at these bugs with patches. One thing you > might look at is how long the patch has been awaiting review: this one, for > example, was written for MW 1.17; the current version is 1.20.alpha. I would like to point out that the problem here is not reviewing the patch; I can update it to trunk and submit it to gerrit right away, but the problem is deciding how exactly this feature should be implemented. See for example comment 46 and related comments.
There is no way I can decipher comment 46 but I am glad to see that this bug (feature) is still being considered :)
Maybe Wikidata will give a solution to this problem? http://meta.wikimedia.org/wiki/Talk:Wikidata#Interwikis_for_Wikisource_and_Wikiquote_for_example
There is [[mw:extension:RelatedSites]] in Wikivoyage which puts links to siblings in the sidebar; it's just not active on any other WMF wikis.
https://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_interface
https://blog.wikimedia.org/2013/06/11/update-wikisource-vision-may/
This seems covered now with bug 54374 closed. Good to close?
(In reply to Lydia Pintscher from comment #64) > This seems covered now with bug 54374 closed. Good to close? I don't think so (otherwise that bug would have been duped to this long ago I suppose?). I've posted my proposal on how to identify next steps, and requirements for this bug to be considered fixed, in http://lists.wikimedia.org/pipermail/wikidata-l/2014-April/003698.html
