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

silsor wrote:

This should apply to categories as well.

koneko wrote:

so true, so true.

Yes, I agree.

zigger wrote:

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

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.

ui2t5v002 wrote:

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

ssd.wiki wrote:

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.

Wiki.Melancholie wrote:

See also: bug 4547 (enable interwiki templates (common
templates))

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

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.

chtitux wrote:

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

gangleri wrote:

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

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

ayg wrote:

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

bugs wrote:

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

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

Closing, Comment #15 sums it up.

ayg wrote:

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.

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.

Removed 'schema-change' keyword. No patch attached that requires a schema change.

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.

This

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

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

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.

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.

re-setting priority to low, *again*.

Unless your name is hexmode, please don't mess with priority settings.

That means our voice can be dumped into rubbish bin? Then what's the point of having the "vote"?

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

I think [[m:Wikidata]] will solve the part of this bug related to Interlanguage links.

I wouldn't call a core bug fixed when you have to install a large extension to fix it.

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

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

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.

(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

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.

This bug discussion is conflating two different bugs, one regarding interwiki links and one regarding categories. I'm going to restore this bug to its original scope (interwiki links) and resurrect bug T2201 (regarding categories). That way they can be addressed separately.

This was specifically about interwikis, I suggest to revert the merge-and-reopen.