Last modified: 2014-11-17 10:34:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 708 - Interproject links
Interproject links
Status: NEW
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 91 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: crosswiki
: 195 4208 5396 6347 6501 7323 7428 (view as bug list)
Depends on: 54374
Blocks: 64475
  Show dependency treegraph
 
Reported: 2004-10-13 23:03 UTC by Anthere
Modified: 2014-11-17 10:34 UTC (History)
46 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
GUI mock-up of interproject (sister project) links (115.46 KB, image/png)
2004-11-06 23:22 UTC, Erik Moeller
Details
Possible implementation of interproject links (8.78 KB, patch)
2011-07-14 13:41 UTC, Robin Pepermans (SPQRobin)
Details

Description Anthere 2004-10-13 23:03:57 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.
Comment 1 Yann Forget 2004-10-18 10:56:38 UTC
I think this feature is a must for all projects. 
Comment 2 Andre Engels 2004-10-22 18:54:06 UTC
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.
Comment 3 Erik Moeller 2004-11-06 23:22:16 UTC
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.
Comment 4 Brion Vibber 2004-11-06 23:24:07 UTC
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).
Comment 5 Gerard Meijsssen 2004-11-09 19:09:12 UTC
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
Comment 6 JeLuF 2004-11-13 08:53:51 UTC
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.
Comment 7 Rowan Collins [IMSoP] 2004-12-17 20:08:55 UTC
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".
Comment 8 KirbyMeister 2004-12-17 20:22:03 UTC
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.
Comment 9 Rowan Collins [IMSoP] 2004-12-17 20:33:26 UTC
(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..."
Comment 10 KirbyMeister 2004-12-17 20:46:51 UTC
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.
Comment 11 Brion Vibber 2004-12-17 21:19:00 UTC
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.
Comment 12 kelvSYC 2004-12-23 21:22:08 UTC
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?
Comment 13 Dori 2005-01-03 00:18:15 UTC
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.
Comment 14 bdk 2005-12-14 09:48:05 UTC
*** Bug 4208 has been marked as a duplicate of this bug. ***
Comment 15 Erik Moeller 2005-12-14 16:53:30 UTC
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.
Comment 16 Melancholie 2006-03-22 03:44:03 UTC
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.
Comment 17 Brion Vibber 2006-03-30 03:15:05 UTC
*** Bug 5396 has been marked as a duplicate of this bug. ***
Comment 18 Leonardo Gregianin 2006-04-15 02:35:19 UTC
Portuguese Wikipedia too implementation sister projects in Javascript based on
German Wiktionary. See [[w:pt:Template:Correlatos]].
Comment 19 lɛʁi לערי ריינהארט 2006-04-17 22:09:08 UTC
(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]]
Comment 20 555 2006-04-17 22:47:54 UTC
(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]]
Comment 21 Rob Church 2006-06-17 20:02:31 UTC
*** Bug 6347 has been marked as a duplicate of this bug. ***
Comment 22 Rob Church 2006-06-30 16:32:15 UTC
*** Bug 6501 has been marked as a duplicate of this bug. ***
Comment 23 Brion Vibber 2006-09-15 07:36:36 UTC
*** Bug 7323 has been marked as a duplicate of this bug. ***
Comment 24 e_veersma 2006-09-18 20:11:08 UTC
Get it done quickly. This bug is here now for 2 years and we 
still use this worthles system. 
Comment 25 Brion Vibber 2006-09-28 01:03:51 UTC
*** Bug 7428 has been marked as a duplicate of this bug. ***
Comment 26 Jamie Hari 2007-07-13 04:20:42 UTC
(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?
Comment 27 Brion Vibber 2007-07-13 14:01:26 UTC
No significant change has been made to the system.
Comment 28 Rob Church 2007-09-18 10:38:37 UTC
*** Bug 195 has been marked as a duplicate of this bug. ***
Comment 29 SJ 2008-01-30 06:46:20 UTC
I'm getting excited just thinking about the /possibility/ of this bug being addressed.
Comment 30 Melancholie 2008-05-31 02:26:58 UTC
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!
Comment 31 Niklas Laxström 2008-07-12 08:03:00 UTC
(In reply to comment #30)
> 2. Give those links the appropriate project names in *Names.php*!

Those don't belong there.
Comment 32 Vik 2008-10-08 01:50:30 UTC
Why can't we just do [[q:simple:Foo]]?
Comment 33 Niklas Laxström 2009-04-07 07:53:24 UTC
Btw I like the way this in done in English Wikipedia, where more information about the target is given than just a project name.
Comment 34 Jeff G. 2009-04-08 04:34:45 UTC
Niklas Laxström <niklas.laxstrom@gmail.com> changed:
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Priority|Highest                     |Low

I have reverted the above change in priority.
Comment 35 Niklas Laxström 2009-04-08 08:24:53 UTC
> I have reverted the above change in priority.
Unless you are a developer, don't touch them. This is not a wiki.

Comment 36 James Sully 2009-11-17 08:48:18 UTC
I agree, i think that this merits a spot above the language box.
Comment 37 Nemo 2010-08-12 14:13:57 UTC
(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.
Comment 38 Yair Rand 2011-02-21 16:11:14 UTC
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.
Comment 39 Robin Pepermans (SPQRobin) 2011-07-14 13:41:46 UTC
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).
Comment 40 Nemo 2011-07-14 13:56:21 UTC
*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).
Comment 41 aaron.adrignola 2011-07-14 14:11:46 UTC
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.
Comment 42 Nemo 2011-07-14 14:41:22 UTC
(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?
Comment 43 aaron.adrignola 2011-07-14 15:34:22 UTC
(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
Comment 44 Nemo 2011-07-14 17:59:54 UTC
(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.
Comment 45 aaron.adrignola 2011-07-14 18:23:10 UTC
(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.
Comment 46 Robin Pepermans (SPQRobin) 2011-07-17 01:48:51 UTC
(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.
Comment 47 Nemo 2011-07-17 08:43:07 UTC
(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.
Comment 48 Nemo 2011-07-17 08:58:09 UTC
(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]].
Comment 49 Patrik Ekengren 2011-08-08 20:27:19 UTC
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.
Comment 50 Tivedshambo 2011-12-29 10:18:20 UTC
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)
Comment 51 TED 2012-02-28 22:43:17 UTC
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 ?
Comment 52 Robin Pepermans (SPQRobin) 2012-02-28 22:55:06 UTC
(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.
Comment 53 TED 2012-02-28 23:08:18 UTC
(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.
Comment 54 au 2012-06-16 10:55:06 UTC
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!
Comment 55 Waldir 2012-06-18 10:30:22 UTC
(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 :)
Comment 56 au 2012-06-18 11:09:25 UTC
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.
Comment 57 Amgine 2012-06-18 15:12:33 UTC
(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!
Comment 58 Robin Pepermans (SPQRobin) 2012-06-18 15:20:21 UTC
(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.
Comment 59 Anthere 2012-06-18 19:06:46 UTC
There is no way I can decipher comment 46 but I am glad to see that this bug (feature) is still being considered :)
Comment 60 Kersti Nebelsiek 2012-07-25 09:21:33 UTC
Maybe Wikidata will give a solution to this problem?
http://meta.wikimedia.org/wiki/Talk:Wikidata#Interwikis_for_Wikisource_and_Wikiquote_for_example
Comment 61 Carl Austin Bennett 2013-02-10 20:58:32 UTC
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.
Comment 64 Lydia Pintscher 2014-04-12 10:47:12 UTC
This seems covered now with bug 54374 closed. Good to close?
Comment 65 Nemo 2014-04-12 10:56:22 UTC
(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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links