Last modified: 2014-10-25 00:44:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2167, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 167 - Use a dedicated interface for adding interwiki/category links, not wikitext
Use a dedicated interface for adding interwiki/category links, not wikitext
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 48 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 201 3367 4810 14514 (view as bug list)
Depends on: 30345
Blocks: 931 3311 27312
  Show dependency treegraph
 
Reported: 2004-08-18 19:33 UTC by SJ
Modified: 2014-10-25 00:44 UTC (History)
23 users (show)

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


Attachments

Description SJ 2004-08-18 19:33:39 UTC
Interwiki links should be stored as metadata pertaining to an article, not as
part of the article text.  It should be parsed out when saving the page, not
when loading it; and perhaps added back in on edit, until a better interface is
designed.  

(There should really be a better interface, as well, with lang-code and
page-title boxes for new related langs -- adding a lang-link should not require
a full save of the page, or an entry in the standard history list.  Other
improvements will be possible once this metadata is moved outside the article body.)
Comment 1 Brion Vibber 2004-08-24 04:50:47 UTC
*** Bug 201 has been marked as a duplicate of this bug. ***
Comment 2 Jeff Bonham 2005-04-14 19:28:51 UTC
This should apply to categories as well. 
Comment 3 Darkoneko 2005-04-14 21:12:13 UTC
so true, so true.
Comment 4 Yann Forget 2005-04-24 15:22:19 UTC
Yes, I agree. 
Comment 5 Zigger 2005-09-06 13:16:20 UTC
*** Bug 3367 has been marked as a duplicate of this bug. ***
Comment 6 Tim Starling 2006-01-06 12:10:28 UTC
Parsed out on save and added in on edit? Sounds like a waste of time to me.
Adding a better UI is all very well, and indexing interlanguage links would be
nice, but neither of those requires removing interlanguage links from the
article text. 
Comment 7 Omegatron 2006-01-06 15:22:05 UTC
(In reply to comment #6)
> Parsed out on save and added in on edit? Sounds like a waste of time to me.

I hope not.

> nice, but neither of those requires removing interlanguage links from the
> article text. 

I think interlanguage and categories should be removed from the text and added
to articles through some other type of interface.
Comment 8 ssd 2006-01-07 09:45:50 UTC
This would be useful because it would allow the following features:
* trivial category moves without editing every single article
* category redirect

Bugs this would affect: (might help or hurt)
* Bug 835 (transcluding a page containing categories)
* complications with deletion, move, and undeletion of pages: Bug 632, Bug 1119,
others

Depending on how this was implemented, it might make some problems worse. 
For example:
* If the metadata is the only place the category is stored, if a vandal
redirected a category to another existing category, the two could be
unintentionally merged, making it difficult to separate them.
* If a user accidently left the : out of a category link, the page would be put
into the category (as is now), and the text would be removed from the article
instead of left in place for correction.

I'm sure I've not begun to cover the complexities of this. 
Comment 9 Melancholie 2006-01-26 02:58:36 UTC
See also: bug 4547 (enable interwiki templates (common 
templates))
Comment 10 Brion Vibber 2006-01-31 20:55:27 UTC
*** Bug 4810 has been marked as a duplicate of this bug. ***
Comment 11 Tim Starling 2006-04-07 12:17:00 UTC
A big advantage of putting metadata in the article text is that you automatically 
get basic wiki features like versioning and review. I'm leaning strongly towards 
duplicating interlanguage links to an indexed table, not moving them.
Comment 12 Théo 2006-04-16 10:11:13 UTC
Well, why putting metadas in other "box" breaks revisions of the article ?
The new "box" (I see the metadata in a textarea tag, and an other column in th
SQL table) is like a paragraph in the article.
When you change it, the articles gets a new version. (I think distinct
versionning for the core and the metadata is bad). When you compare 2 versions,
metadatas paragraph is compared too.
So, we keep "basic wiki features like versioning and review".
An idea for Google Summer of code ?
http://meta.wikimedia.org/wiki/Summer_of_Code_2006
Comment 13 lɛʁi לערי ריינהארט 2008-01-02 01:24:52 UTC
regarding half of the summary / subject:

[[commons:special:Prefixindex/IW:!]] is completely empty.

Why not have [[commons:image:IW:w:Esperanto]] or [[commons:image:IW:w:Esperanto.txt]] a pure text file type which should be parsed from wikitext and generate the [[MediaWiki:Otherlanguages]] ( « In other languages ») links.

There are only a few rules:

a) self refering links (when the language / project code of an interwiki matches the project code of that wiki) should be ignored
b) it should be possible to costumise the sort order of the inter wiki / inter project links; many wikis have guidlines about how this


For the projects where the WMF runs projects in many languages as [[b:]], [[n:]], [[q:]], [[s:]], [[v:]], [[w:]], [[wikt:]] neither [[commons:image:IW:w:Esperanto.txt]] · [[commons:image:IW:b:Esperanto.txt]] nor
[[commons:image:IW w/Esperanto.txt]] · [[commons:image:IW b/:Esperanto.txt]] would conflict between the sister projects.

Another solution would be a naming convention as
[[commons:image:Esperanto.txt/IW b]]
[[commons:image:Esperanto.txt/IW v]]
[[commons:image:Esperanto.txt/IW w]]
[[commons:image:Esperanto.txt/IW wikt]]

This way the pages can be found via [[commons:special:Prefixindex/image:Esperanto.txt]].


note:
The solution relates to Product WikiMedia; an extension could be involved as well.

Best regards Reinhardt [[user:Gangleri]]
Comment 14 SJ 2008-01-30 06:30:09 UTC
Agreed with Theo.

Pages should be stored as something like 
{page-content, list-of-category-ids, interwiki-list-id}

When there is a category typo, updating the cat name should update everything that was in that cat 
(hence you're referencing a category-id, and not a category itself, in an article).  

When you update an interwiki list, every element on that list should be updated to have the new list of interwikis [1]. 

As for ssd's concerns:
 * redirecting a category to an existing category : just don't let this happen (or make it an admin-only action, like history merge; require category deletion and undeletion).  moving a category is ok as long as there is no merging involved.
 * losing data when a colon is accidentally left out : I no longer thing that "write to db on save, write into article on wikitext render" is appropriate.  Better to simply have this data in a different table, and to present it separately from the rest of the article-editing.  There should be two distinct interfaces for editing interwiki links on the one hand, and categories on the other.  Both should offer the use of simple tools or auto-completions to select from existing terms [in other languages and in the current language's set of cats].  We may as well do this right as long as the bug has stayed open for so long.

[1] you can have a special case for non-reciprocal interwiki links.  These should probably show up differently in the displayed list as well, an indication which is currently confusingly absent.  For instance, if two languages distinguish 'education' from 'pedagogy' and another twenty do not, the other twenty have to choose which of the two terms they link to in the case of the two outliers.  this can most simply be one interwiki-list of twenty-two, and another interwiki-list of two-plus-twenty where the twenty have an asterisk next to them (indicating that they are not reciprocal links).

Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-30 15:51:18 UTC
(In reply to comment #14)
>  * losing data when a colon is accidentally left out : I no longer thing that
> "write to db on save, write into article on wikitext render" is appropriate. 
> Better to simply have this data in a different table, and to present it
> separately from the rest of the article-editing.

This is more or less what this bug is about.  It's not fixed as long as the metadata is added inline.  We already store stuff like category data in separate tables, but it's duplicated from the wikitext, not independent of it.  I'm going to rename this bug to make it clear that we're talking about replacing the wikitext addition of categories/interwikis entirely, since that's what it seems to be attracting interest for.  Another bug could be created to add the interface without necessarily replacing the current wikitext one, i.e., one that might just secretly edit the saved wikitext after submission to change the metadata.  That bug would block this one.

However, you'd have to address how to have templates include categories, and especially how they could include dynamic categories.  Currently templates can use any kind of wikitext function to decide on category names, and can use arbitrarily complex nesting and conditionals to decide whether to even include a category in the first place.  How would you replicate this functionality without using wikitext?  It would be nice efficiency-wise to be able to ditch dynamic categories for non-substed templates -- you could avoid the entire job queue issue, if you went far enough -- but I very much doubt it's acceptable.  So you'd have to have some kind of magic word to allow categories to be added in wikitext anyway . . . which strikes me as bringing us back to where we started, pretty much.  This is probably WONTFIX due to this implication, although if you have any ideas feel free to share them.
Comment 16 Steve Bennett 2008-03-19 13:12:34 UTC
Here's a thought:
Store two texts for each article: the article text and the metadata text, both of which contain wikitext. The key difference being that in the article text, metadata is always rendered literally ([[category:foo]] is a link to a category), and in the metadata text, nothing can ever be rendered ([[:category:foo]] is a no-op).

In the short term, these two boxes could simply be displayed as such. Later, the metadata text editor could be improved, since no one will care whether categories come before interwikis or vice versa. Magnus's code could be used:

http://en.wikipedia.org/wiki/User:Magnus_Manske/less_edit_clutter.js

If compatibility with other software is required, perhaps MediaWiki could send the two wikitexts combined, upon request, with some sort of separation marker like <!-- metadata -->. Since article text followed by metadata text is always valid wikitext, this is feasible.

I haven't thought this through much, so don't shoot me. :)

Steve
Comment 17 Siebrand Mazeland 2008-08-13 21:11:59 UTC
*** Bug 14514 has been marked as a duplicate of this bug. ***
Comment 18 Aaron Schulz 2008-09-05 03:41:49 UTC
Closing, Comment #15 sums it up.
Comment 19 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-09-05 14:19:24 UTC
Disagree, reopening.  HotCat actually shows that it's potentially pretty useful to be able to manually manipulate category lists, even if you can't modify template-included ones without editing the wikitext.  Something like HotCat deserves to be in core, IMO.
Comment 20 Amir E. Aharoni 2008-09-15 07:02:31 UTC
I opened a new bug requesting to enable the new Interlanguage Extension in Wikipedia.

It is not the same request as this one, but it is closely related and may solve the same problems in a different way.

See bug 15607.
Comment 21 Siebrand Mazeland 2009-02-02 15:57:39 UTC
Removed 'schema-change' keyword. No patch attached that requires a schema change.
Comment 22 SJ 2009-04-18 22:38:08 UTC
Amir's new bug #15607 is useful and relevant.  I'm pushing for that to be fixed so that there is a basis for discussing the schema change implied in this bug. 

I don't agree with Aryeh's renaming, but there should indeed be two separate bugs.

== under the group of 'multiwiki use of mediawiki' ==

1) provide a way to identify a keyword for an article, and a url where one can go to find the set of interwiki links associated with it.  I imagine this as a schema change that adds a (keyword_id) to each article, a (keyword_id, keyword) table, and globally set (interwiki_url) which is a regexp indicating where to insert a keyword to get the interwiki list for that article.  

 1a) make this work with other languages of the same project on the same servers

 1b) make it work as well with wikipedia articles about the same topic (in a selected # of languages)
This could involve a script that lets you autopopulate a local interwiki with a selected # of languages of wp articles, and an optional fallback to a wikipedia interwiki url if none other is available. 
 
     Related interface changes would include a small header above the interlang list indicating the jump from local interlang links to ''wikipedia'' links.


== under the group of 'wikimedia interfaces' ==

2) provide a separate interface for modifying interlang links for a topic - perhaps using the interlanguage extension and simply holding all of that on another wiki (as with Commons).  This interface should allow one to indicate special cases, such as topics with multiple definitions in one language but single definitions in another, and other cases where interlang links are not reciprocal.
Comment 23 Krinkle 2011-02-21 15:17:41 UTC
This
Comment 24 Krinkle 2011-02-22 18:49:10 UTC
(In reply to comment #23)
> This

..message failed and I dont know what I was writing here. Will CC-follow anyway and see what happends.
Comment 25 Krinkle 2011-03-16 00:36:53 UTC
So main points that need attention here:
* If and how do we: Version, review/patrol and log changes made to meta data like Categories and interlanguage links ?
* How to solve edit conflicts ?
* How to handle difference view ?
* What about undo/revert ?

Except for edit conflict and undo/revert Extension:AbuseFilter [1] has done an attempt at solving this. They keep a seperate table for their data with all versions [2] and a note about the action is logged in mw_logging [3].
When viewing the differnce it consists of table with the difference per-heading [4]



[1] http://www.mediawiki.org/wiki/Extension:AbuseFilter
[2] http://i.imgur.com/gv1Xi.png and http://i.imgur.com/VyGEO.png
[3] http://i.imgur.com/qQYAg.png
[4] http://i.imgur.com/7x2mc.png
Comment 26 Danny B. 2011-03-17 18:26:04 UTC
Suggesting to split this to two different bugs since interwiki and category links are not of the same type as well as categories might be desired to be inserted via templates while interwikis are not.

Hence solution for separated interwiki is simple and easily doable with current mediawiki, solution for categories is not.
Comment 27 Amir E. Aharoni 2011-03-21 13:28:02 UTC
Interwikis actually (In reply to comment #26)
> categories might be desired to be
> inserted via templates while interwikis are not.

Interwikis actually can be inserted using templates, and it is actually done, for example for template documentation pages in en.wikipedia and also on discussion pages, so that the intewikis won't interfere with the frequently edited bottom thread.
Comment 28 Bawolff (Brian Wolff) 2011-12-31 10:37:13 UTC
re-setting priority to low, *again*.

Unless your name is hexmode, please don't mess with priority settings.
Comment 29 石庭豐 2011-12-31 10:54:53 UTC
That means our voice can be dumped into rubbish bin?  Then what's the point of having the "vote"?
Comment 30 Bawolff (Brian Wolff) 2011-12-31 11:24:46 UTC
(In reply to comment #30)
> That means our voice can be dumped into rubbish bin?  Then what's the point of
> having the "vote"?

Its been publicly stated in several places for quite a long time that votes are not taken in to consideration when deciding where development effort is put (Popular opinion is taken into consideration somewhat, but not in the form of "votes", generally). The intention behind the voting module is to allow people to have favourites lists of bugs for easy tracking. 

Many considerations go into prioritizing bugs (or from what I understand, I myself generally don't go around prioritizing bugs). How many people are affected, how severely they are affected, how much people want the new behaviour, how difficult the bug is to fix (especially, relative to how many problems the bug is causing), etc.

In any case, its perfectly possible to search the bugzilla db by number of votes (Even though we generally don't look at votes, some people do look at what is voted high when looking for things to fix). Artificially inflating the priority would just make the field useless, it won't make the bug any more "important". (About 50% of bugs are considered super-important to someone somewhere in the universe, if everyone set there favourite bug to 'highest', it would just make the priority field meaningless).
Comment 31 Helder 2012-08-14 01:51:10 UTC
I think [[m:Wikidata]] will solve the part of this bug related to Interlanguage links.
Comment 32 Daniel Friesen 2012-08-14 04:43:12 UTC
I wouldn't call a core bug fixed when you have to install a large extension to fix it.
Comment 33 Quim Gil 2014-04-12 07:14:22 UTC
(In reply to Daniel Friesen from comment #32)
> I wouldn't call a core bug fixed when you have to install a large extension
> to fix it.

Apart from Wikimedia, are there other wiki farms with wikis organized by language, and therefore using interwiki links? Is any MediaWiki user not involved in Wikimedia asking for this feature? I'm honestly thinking who else apart from Wikimedia needs to solve this problem with interwikis.



Then the part about categories... it is really a very different problem. First let me note that the initial reporter didn't mention categories in the title or comment 0, this was added by another user later on. Editors use HotCat, aren't they happy with it? Enabling HotCat in MediaWiki is simple. Someone asked that such functionality should be included in Core. However, the trend is not to inject more features in our already big MediaWiki Core, but user extensions et al to bring more functionality.


For these reasons I believe this 2004 report could be resolved as FIXED in 2014.
Comment 34 Kunal Mehta (Legoktm) 2014-04-12 07:25:26 UTC
(In reply to Quim Gil from comment #33)
> (In reply to Daniel Friesen from comment #32)
> > I wouldn't call a core bug fixed when you have to install a large extension
> > to fix it.
> 
> Apart from Wikimedia, are there other wiki farms with wikis organized by
> language, and therefore using interwiki links? Is any MediaWiki user not
> involved in Wikimedia asking for this feature? I'm honestly thinking who
> else apart from Wikimedia needs to solve this problem with interwikis.
> 

Take a look at the bottom of <http://en.uncyclopedia.co/wiki/Special:Interwiki>. While not the size of WMF wikis, Uncyclopedia certainly does use interlanguage links.
Comment 35 Quim Gil 2014-04-12 07:39:54 UTC
Good, thank you, I didn't know that.

Now, what does require more effort: deploying the Wikibase extension or developing this feature from scratch?

Having a farm of language wikis connected with interwikis is a very special use case. Wikimedia has solved this problem in one way that works for Wikimedia editors. Once you are in a similar situation, deploying Wikibase probably makes more sense than developing something from scratch.

In any case I don't see WMF resources being put into the feature requested here, now that Wikidata exists.
Comment 36 Amir E. Aharoni 2014-04-13 13:40:18 UTC
(In reply to Quim Gil from comment #33)
> Then the part about categories... it is really a very different problem.
> First let me note that the initial reporter didn't mention categories in the
> title or comment 0, this was added by another user later on. Editors use
> HotCat, aren't they happy with it? Enabling HotCat in MediaWiki is simple.
> Someone asked that such functionality should be included in Core. However,
> the trend is not to inject more features in our already big MediaWiki Core,
> but user extensions et al to bring more functionality.
> 
> 
> For these reasons I believe this 2004 report could be resolved as FIXED in
> 2014.

I agree with Quim. Using Wikibase and VisualEditor is a reasonable way to solve these problems today. They can be installed on any wiki and they are not specific to Wikipedia. Working on adding this functionality to core when we already have extensions that do it fairly well is wasteful.

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


Navigation
Links