[Goal] Sitelinks to Incubator, OldWikisource and BetaWikiversity
Open, Stalled, LowPublic

Description

All language codes permissible for wikimedia projects (ie generally ISO 639-1 and -3) should be available for choosing in the sitelinks sections of Wikidata. When a code is entered of which there is no subdomain (of Wikipedia, Wikivoyage, etc.) yet, the target page should be searched on Incubator. (e.g. Wikipedia sitelinks, code liv, page name X => Search for incubator:Wp/liv/X and allow addition of the link if that page exists).


Version: unspecified
See Also:
T37960: add config variable to hide incubator test wikipedia langlinks on wikipedia projects by default
T73685: [Task] Turn mediawiki.org into a Wikidata client
list of wikis that have Wikimedia permanent duplicated pages (Q21286738)


Also proposed in Community-Wishlist-Survey-2016. Received 54 support votes, and ranked #18 out of 265 proposals. View full proposal with discussion and votes here.

Details

Reference
bz52971

Related Objects

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz52971.
bzimport added a subscriber: Unknown Object (MLST).

Addition for the 2 projects whose test-projects are not hosted on Incubator:
For Wikisource and Wikiversity, the usage of any ISO code not currently having an open subdomain should lead to the page to be searched on OldWikisource and BetaWikiversity, respectively. Then allow addition of the link if the page exists there (no attention needs to be paid to prefixes here, since only Incubator uses them).

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

Can we have a timeline for this?

I don't have one yet, sorry.

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

This should also allow sitelinks to pages in different names spaces. English wikipedia, for instance, can have an article, a category, a portal, a wikiproject, all dealing with the same topic and these should all link to the same wikidata item.

There is also a case for allowing multiple links from the same namespace. English wikipedia Can have an article, a list and an outline (or a topic outline) about the same item though spanish wikipedia puts lists in a separate "Annexo:" namespace

Micru added a comment.Mar 13 2014, 6:02 PM

Maybe all that could go into the new "Special" sitelink category?
https://bugzilla.wikimedia.org/show_bug.cgi?id=55507

I think "special" sitelinks is for multilingual pages like commons so it doesn't help with monolingual pages like these.

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

mul for OldWikisource and BetaWikiversity both work now. I haven't checked incubator

Doesn't help much if you can only link to one page per wiki.

mxn added a subscriber: mxn.Nov 24 2014, 8:56 PM
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher lowered the priority of this task from Normal to Low.Dec 27 2014, 2:01 PM
Lydia_Pintscher set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 20 2015, 2:54 PM

Developers: will this task get easier if T64717 is implemented?

Doesn't help much if you can only link to one page per wiki.

This is a more general problem related to all Wikisource subdomains, not just mul. In every subdomain you can have several versions of the same text, corresponding to different editions or translations, so we need to be able to link all the editions on one subdomain with all the editions on all the other subdomains.
This will hopefully be solved by T128173, in the meantime we'll have to use disambiguation pages to provide adequate linking.
Anyway it should not be a blocking issue for the current task.

On Meta, we have a list of translations usually at he beginning of each translated wiki page. Also these were better off in the place where other wikis have their interlanguage link lists.

Mentioned in SAL [2016-05-03T15:44:18Z] <aude@tin> Synchronized dblists/wikidataclient.dblist: Remove beta.wikiversity as a client. See T54971 (duration: 00m 25s)

srishakatux updated the task description. (Show Details)Feb 6 2017, 8:49 AM
srishakatux updated the task description. (Show Details)
srishakatux updated the task description. (Show Details)Feb 11 2017, 1:32 AM
This task was proposed in the Community-Wishlist-Survey-2016 and in its current state needs owner. Wikimedia is participating in Google Summer of Code 2017 and Outreachy Round 14. To the subscribers -- would this task or a portion of it be a good fit for either of these programs? If so, would you be willing to help mentor this project? Remember, each outreach project requires a minimum of one primary mentor, and co-mentor.

It's fairly complex unless one attempts to solve it from the client wiki.

It's fairly complex unless one attempts to solve it from the client wiki.

The original request is that it should be possible to add sitelinks using any of the language codes that don't have a subdomain, which I guess is the difficult part. But can we just use one language code ("mul" seems a good candidate) to identify the Incubator / BetaVersity / MulSource projects, and add sitelinks using that code, and that code only? This should be easier to implement, I suppose. It would be much better than doing nothing, and it could be a first step towards the complete solution.

Lydia_Pintscher changed the task status from Open to Stalled.Feb 28 2017, 10:53 AM

This is not a GSoC task. There is also no clear plan of how to do this because it breaks a basic assumption of Wikibase.

This is not a GSoC task. There is also no clear plan of how to do this because it breaks a basic assumption of Wikibase.

What is the basic assumption that is being broken?

That a given wiki only has one page about a given topic.

"mul" seems a good candidate

I agree: it's the ISO 639-3 code for "multiple languages", so should be able to fit in as all other language codes do. (I think; I'm no wikibase hacker).

That a given wiki only has one page about a given topic.

Regarding Mul Wikisource, this assumption is still intact: every page represents a different edition of some text. You can have a page with the translation of Hamlet in Hindi, and another page with the translation in Neapolitan. But they are still different "topics". Otherwise, if you consider them to be instances of the same "topic" i.e. the work Hamlet, then your assumption fails for all Wikisource projects... en.wikisource can host different editions of Hamlet, and fr.wikisource can have multiple translations, and this is not at all a problem.

On Incubator and BetaVersity, if you want to keep your assumption working, just create a disambiguation page which will be the "one" page about the topic; and from there you have links to different pages according to the language. Of course this is not perfect, but at least these projects will finally get a usable Wikidata access, and it will be much better than to keep ignoring them forever.

The original request is that it should be possible to add sitelinks using any of the language codes that don't have a subdomain, which I guess is the difficult part. But can we just use one language code ("mul" seems a good candidate) to identify the Incubator / BetaVersity / MulSource projects, and add sitelinks using that code, and that code only? This should be easier to implement, I suppose. It would be much better than doing nothing, and it could be a first step towards the complete solution.

That doesn't work on Incubator because there would be multiple pages, and for the proper use of interwiki links it is also necessary to have it clear which language the page is in.

The original request is that it should be possible to add sitelinks using any of the language codes that don't have a subdomain, which I guess is the difficult part. But can we just use one language code ("mul" seems a good candidate) to identify the Incubator / BetaVersity / MulSource projects, and add sitelinks using that code, and that code only? This should be easier to implement, I suppose. It would be much better than doing nothing, and it could be a first step towards the complete solution.

That doesn't work on Incubator because there would be multiple pages, and for the proper use of interwiki links it is also necessary to have it clear which language the page is in.

What's wrong in the "Other languages" label?
Let's be honest. We all know that the "proper" solution will never be implemented. A slightly less proper solution is still much better than no solution.

For Incubator, I think it would be good if they'd have at least random access to Wikidata to read data from items. Even if it would mean specifying the item to read that from, this would allow to build infoboxes and display data from Wikidata.

Recent imports of old-style interwikis from new Wikipedias that were prepared on Incubator was fairly efficient and quick.

Is it within the scope of this task that ordinary wikipedia with multiple page for every single concept written in multiple script cannot be linked to same wikidata concept entry?

Liuxinyu970226 added a comment.EditedMar 4 2017, 12:26 PM

Is it within the scope of this task that ordinary wikipedia with multiple page for every single concept written in multiple script cannot be linked to same wikidata concept entry?

Most of such Wikipedias that a random topic is written on more than one articles, and can't be merged due to policy [citation needed]/variants (can't be handled by MediaWiki-Language-converter?)..., as far as I reviewed, are already marked as Wikimedia permanent duplicated pages. So where's the examples that are not in this case?

Koavf added a subscriber: Koavf.Jul 8 2017, 5:28 PM
Liuxinyu970226 added a subscriber: gh87.EditedJul 15 2017, 12:04 PM

@gh87 Since you're one that opposing the closure and migration of BetaWikiversity, can you please suggest your way on handling links between 3 projects, 8 monolingual projects, and 5 multilingual projects? As a simple reason because we need your inputs, because we still haven't a consensus on this task (as you see Status: Stalled and priority: Low)

Liuxinyu970226 removed a subscriber: JohnLewis.EditedJul 15 2017, 12:07 PM

kicked up the WMF banned user to make subscribers more clean (I cherish the memory of Purodha).

gh87 added a comment.Jul 15 2017, 10:58 PM

@Liuxinyu970226 Hmm... maybe we can create subtasks. Otherwise, maybe reject this task and then create separate tasks for Beta WV, for Old Wikisource, and for Incubator.

Liuxinyu970226 added a comment.EditedJul 15 2017, 11:07 PM

@Liuxinyu970226 Hmm... maybe we can create subtasks. Otherwise, maybe reject this task and then create separate tasks for Beta WV, for Old Wikisource, and for Incubator.

Mnn, I aganist splitting, the problems could be same (like T50032), rather I suggest to make this task as a sub- Epic (or a Goal?)

Liuxinyu970226 renamed this task from Sitelinks to Incubator, OldWikisource and BetaWikiversity to [Future Goal] Sitelinks to Incubator, OldWikisource and BetaWikiversity.Jul 17 2017, 10:42 AM
Liuxinyu970226 added a project: Goal.

Would be sense to use Goal...

Liuxinyu970226 renamed this task from [Future Goal] Sitelinks to Incubator, OldWikisource and BetaWikiversity to [Goal] Sitelinks to Incubator, OldWikisource and BetaWikiversity.Jul 17 2017, 10:45 AM
Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptJul 25 2017, 11:10 PM

We may introduce the concept of "virtual" site. There will still be one siteline per wiki, but some wikis don't have it's own site and exist on another site.

Liuxinyu970226 added a comment.EditedThu, Aug 31, 3:08 PM

We may introduce the concept of "virtual" site. There will still be one siteline per wiki, but some wikis don't have it's own site and exist on another site.

I don't think this can be helpful, as it still won't resolve issues that author asked. Anyway, I OPPOSE using Wikimedia permanent duplicated pages (Q21286738) for 3 projects as it can only result harmful conflicts.

My suggestion is that we should implement a configuration setting that can be called "$wgWikibaseAllowMultipleSitelinksInOneSite", set false as default, only set to true for those three links.

Then in list of sitelinks (use the Main pages (Q5296) as example):
Wikisource v
...
ml പ്രധാന താൾ
mr मुखपृष्ठ
mul v

  • Main Page (en)
  • Main_Page/IsiXhosa (xh)

...
nl Hoofdpagina
no Wikikilden:Forside
...
Wikiversity v
...
ja メインページ
ko 위키배움터:대문
mul v

  • Main_Page (en)
  • Ĉefpaĝo (eo)

...
pt Página principal
ru Заглавная страница
...
Other projects v
commons Main Page
incubator v

  • Incubator:Main_Page (en)
  • Incubator:Main_Page/fr (fr)

...
media MediaWiki
meta Main Page
species Main Page
wikidata Wikidata:Main Page

(I will post my solution for interlanguage lists and for "In other projects" sidebar later, maybe after my DHCP provider's maintaining works done)

Koavf added a comment.Sat, Sep 2, 8:01 PM

For what it's worth, a subtle point about mul.ws may be missed here. The goal of Incubator and beta.wv (which I firmly believe should have been incorporated into Incubator many years ago) is two-fold: two foster small content that can grow into an independent project either from 1.) a closed wiki that used to be live or 2.) a newly-established community. Mul.ws doesn't really function that way--altho some projects do graduate into their own subdomains, 1.) many never will, simply because the corpus of literature doesn't exist and 2.) there are works which *are* themselves multilingual. There is no reason to have (e.g.) a collection of quotations in two different languages but there are very good reasons to hosts books which were published in multiple languages. So the best case scenario for Incubator and beta.wv is that everything graduates and there isn't really much that stays there or "happens" at those wikis other than moving them into maturity and some small coordination. Mul.ws is and should always be a stand-alone project which will harbor content indefinitely.

All this is to say that making interwiki links to Incubator or beta.wv may not be a priority really since the good stuff will just end up graduating anyway but it's *necessary* to be able to interlink with mul.ws.

Well said @Koavf. mulWS is definitely a permanent home for some works and if Wikidata is to function fully there needs to be a means to link to these works. We are falling into an area where it seems that some are wiping their hands and walking away, and that is disrespectful for those pour their time into works yet who are captured by the hierarchy that has been created for them.

Koavf added a comment.EditedSun, Sep 3, 5:58 AM

Very much so. There are perfectly legitimate documents at mul.ws and in addition to being disrespectful for the work put into them, some of those documents are among the few of a given language that even exist. If mul.ws continues in fulfilling its purpose, it will be a very valuable resource for many languages which are more-or-less not literate, endangered, or extinct. That's culturally invaluable. So yes, please make incoming links to mul.ws which is a stable resource that has a functioning subdomain (if memory serves, I was the one who proposed that mul.wikisource.org redirect to wikisource.org). Separate out beta.wv and Incubator if necessary but please move forward on mul.ws.

Edit: [[T1257]]