Page MenuHomePhabricator

Interproject links
Closed, ResolvedPublic

Assigned To
Authored By
bzimport
Oct 13 2004, 11:03 PM
Referenced Files
F1394: Interprojects.patch
Nov 21 2014, 7:07 PM
F1393: interproject.png
Nov 21 2014, 7:07 PM
Tokens
"Like" token, awarded by Kozuch."Like" token, awarded by Nemo_bis."Like" token, awarded by He7d3r.

Description

Author: anthere9

We need interproject links badly. I explained what I was thinking about here :
https://en.wikipedia.org/wiki/Wikipedia:Recipes_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 mentioned 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.


See Also:
T57070: Interproject interwikilinks -same option e.g. for Wiktionary-Wikipedia
https://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_interface

Details

Reference
bz708

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

rowan.collins wrote:

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".

dcrkid wrote:

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.

rowan.collins wrote:

(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..."

dcrkid wrote:

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.

kelvSYC wrote:

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?

slowpoke wrote:

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.

wiki.bugzilla wrote:

*** 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.

Wiki.Melancholie wrote:

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. ***

leogregianin wrote:

Portuguese Wikipedia too implementation sister projects in Javascript based on
German Wiktionary. See [[w:pt:Template:Correlatos]].

gangleri wrote:

(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]]

robchur wrote:

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

robchur wrote:

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

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

e_veersma wrote:

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. ***

webmaster wrote:

(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.

robchur wrote:

*** 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.

Wiki.Melancholie wrote:

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)

  1. Give those links the appropriate project names in *Names.php*!

Those don't belong there.

kooliamdabest wrote:

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.

RSYQFIOJGWZA wrote:

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.

sullyj3 wrote:

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
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).

Attached:

*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).

aaron.adrignola wrote:

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?

aaron.adrignola wrote:

(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.

aaron.adrignola wrote:

(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]].

patrikekengren wrote:

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.

Tivedshambo wrote:

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)

desquil.pub wrote:

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.

desquil.pub wrote:

(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.

audreyt wrote:

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 :)

audreyt wrote:

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.

wmf.amgine3691 wrote:

(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 :)

carlb613 wrote:

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.

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

He7d3r set Security to None.
Glaisher removed a subscriber: Unknown Object (MLST).

Isn’t it resolved with mw:Beta Features/Other projects sidebar?

Potentially, but it needs to be made default on all Wikimedia projects yet. Please propose it on your wikis and file a configuration request!

Potentially, but it needs to be made default on all Wikimedia projects yet. Please propose it on your wikis and file a configuration request!

Won't it be turned on for everyone when it's fully developed (i.e. not beta)?

Won't it be turned on for everyone when it's fully developed (i.e. not beta)?

BetaFeatures is a tool which has no relationship with the beta status of a feature. There are no know bugs for the feature and it's already enabled on multiple wikis by default, it's just a matter of having local consensus for it until it becomes global.

Such great news that it's hard to believe: it seems it's done! T103102 was resolved.

Maybe we can keep this open for 30 days until all the caches expire. By then, we should see everything that can be seen.

Maybe we can keep this open for 30 days until all the caches expire. By then, we should see everything that can be seen.

Those 30 days are over. How to proceed?