Interproject links
OpenPublic

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

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz708.
bzimport created this task.Via LegacyOct 13 2004, 11:03 PM
Yann added a comment.Via ConduitOct 18 2004, 10:56 AM

I think this feature is a must for all projects.

bzimport added a comment.Via ConduitOct 22 2004, 6:54 PM

andreengels wrote:

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.

Eloquence added a comment.Via ConduitNov 6 2004, 11:22 PM

Created attachment 124
GUI mock-up of interproject (sister project) links

This is a simple GUI mock-up of how I intend to implement this.

Attached:

brion added a comment.Via ConduitNov 6 2004, 11:24 PM

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

bzimport added a comment.Via ConduitNov 9 2004, 7:09 PM

gerardm wrote:

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
bzimport added a comment.Via ConduitNov 13 2004, 8:53 AM

jeluf wrote:

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.

bzimport added a comment.Via ConduitDec 17 2004, 8:08 PM

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

bzimport added a comment.Via ConduitDec 17 2004, 8:22 PM

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.

bzimport added a comment.Via ConduitDec 17 2004, 8:33 PM

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

bzimport added a comment.Via ConduitDec 17 2004, 8:46 PM

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.

brion added a comment.Via ConduitDec 17 2004, 9:19 PM

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.

bzimport added a comment.Via ConduitDec 23 2004, 9:22 PM

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?

bzimport added a comment.Via ConduitJan 3 2005, 12:18 AM

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.

bzimport added a comment.Via ConduitDec 14 2005, 9:48 AM

wiki.bugzilla wrote:

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

Eloquence added a comment.Via ConduitDec 14 2005, 4:53 PM

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.

bzimport added a comment.Via ConduitMar 22 2006, 3:44 AM

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.

brion added a comment.Via ConduitMar 30 2006, 3:15 AM
  • Bug 5396 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitApr 15 2006, 2:35 AM

leogregianin wrote:

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

bzimport added a comment.Via ConduitApr 17 2006, 10:09 PM

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

555 added a comment.Via ConduitApr 17 2006, 10:47 PM

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

bzimport added a comment.Via ConduitJun 17 2006, 8:02 PM

robchur wrote:

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

bzimport added a comment.Via ConduitJun 30 2006, 4:32 PM

robchur wrote:

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

brion added a comment.Via ConduitSep 15 2006, 7:36 AM
  • Bug 7323 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitSep 18 2006, 8:11 PM

e_veersma wrote:

Get it done quickly. This bug is here now for 2 years and we
still use this worthles system.

brion added a comment.Via ConduitSep 28 2006, 1:03 AM
  • Bug 7428 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJul 13 2007, 4:20 AM

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?

brion added a comment.Via ConduitJul 13 2007, 2:01 PM

No significant change has been made to the system.

bzimport added a comment.Via ConduitSep 18 2007, 10:38 AM

robchur wrote:

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

Sj added a comment.Via ConduitJan 30 2008, 6:46 AM

I'm getting excited just thinking about the /possibility/ of this bug being addressed.

bzimport added a comment.Via ConduitMay 31 2008, 2:26 AM

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!

Nikerabbit added a comment.Via ConduitJul 12 2008, 8:03 AM

(In reply to comment #30)

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

Those don't belong there.

bzimport added a comment.Via ConduitOct 8 2008, 1:50 AM

kooliamdabest wrote:

Why can't we just do [[q:simple:Foo]]?

Nikerabbit added a comment.Via ConduitApr 7 2009, 7:53 AM

Btw I like the way this in done in English Wikipedia, where more information about the target is given than just a project name.

bzimport added a comment.Via ConduitApr 8 2009, 4:34 AM

RSYQFIOJGWZA wrote:

Niklas Laxström <niklas.laxstrom@gmail.com> changed:

What    |Removed                     |Added

Priority|Highest                     |Low

I have reverted the above change in priority.

Nikerabbit added a comment.Via ConduitApr 8 2009, 8:24 AM

I have reverted the above change in priority.

Unless you are a developer, don't touch them. This is not a wiki.

bzimport added a comment.Via ConduitNov 17 2009, 8:48 AM

sullyj3 wrote:

I agree, i think that this merits a spot above the language box.

Nemo_bis added a comment.Via ConduitAug 12 2010, 2:13 PM

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

Yair_rand added a comment.Via ConduitFeb 21 2011, 4:11 PM

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.

SPQRobin added a comment.Via ConduitJul 14 2011, 1:41 PM

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: Interprojects.patch

Nemo_bis added a comment.Via ConduitJul 14 2011, 1:56 PM

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

bzimport added a comment.Via ConduitJul 14 2011, 2:11 PM

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.

Nemo_bis added a comment.Via ConduitJul 14 2011, 2:41 PM

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

bzimport added a comment.Via ConduitJul 14 2011, 3:34 PM

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

Nemo_bis added a comment.Via ConduitJul 14 2011, 5:59 PM

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

bzimport added a comment.Via ConduitJul 14 2011, 6:23 PM

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.

SPQRobin added a comment.Via ConduitJul 17 2011, 1:48 AM

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

Nemo_bis added a comment.Via ConduitJul 17 2011, 8:43 AM

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

Nemo_bis added a comment.Via ConduitJul 17 2011, 8:58 AM

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

bzimport added a comment.Via ConduitAug 8 2011, 8:27 PM

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.

bzimport added a comment.Via ConduitDec 29 2011, 10:18 AM

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)

bzimport added a comment.Via ConduitFeb 28 2012, 10:43 PM

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 ?

SPQRobin added a comment.Via ConduitFeb 28 2012, 10:55 PM

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

bzimport added a comment.Via ConduitFeb 28 2012, 11:08 PM

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.

bzimport added a comment.Via ConduitJun 16 2012, 10:55 AM

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!

waldyrious added a comment.Via ConduitJun 18 2012, 10:30 AM

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

bzimport added a comment.Via ConduitJun 18 2012, 11:09 AM

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.

bzimport added a comment.Via ConduitJun 18 2012, 3:12 PM

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!

SPQRobin added a comment.Via ConduitJun 18 2012, 3:20 PM

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

Anthere added a comment.Via ConduitJun 18 2012, 7:06 PM

There is no way I can decipher comment 46 but I am glad to see that this bug (feature) is still being considered :)

bzimport added a comment.Via ConduitFeb 10 2013, 8:58 PM

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.

Lydia_Pintscher added a comment.Via ConduitApr 12 2014, 10:47 AM

This seems covered now with bug 54374 closed. Good to close?

Nemo_bis added a comment.Via ConduitApr 12 2014, 10:56 AM

(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 awarded a token.Via WebNov 24 2014, 11:57 AM
mxn added a subscriber: mxn.Via WebNov 24 2014, 8:58 PM
Nemo_bis awarded a token.Via WebDec 12 2014, 7:53 AM
Kozuch awarded a token.Via WebDec 17 2014, 8:35 PM
He7d3r edited the task description. (Show Details)Via WebMar 10 2015, 7:04 PM
He7d3r set Security to None.
Glaisher edited the task description. (Show Details)Via WebMar 11 2015, 3:56 AM
Glaisher removed a subscriber: Unknown Object (MLST).
Nemo_bis added a comment.Via WebMay 4 2015, 7:31 AM

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!

Tacsipacsi added a comment.Via WebMay 4 2015, 8:29 AM

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

Nemo_bis added a comment.Via WebMay 4 2015, 11:21 AM

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.

Add Comment