[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

There are a very large number of changes, so older changes are hidden. Show Older Changes
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.EditedAug 31 2017, 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.EditedSep 2 2017, 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: to 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.EditedSep 3 2017, 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]]

Tpt added a comment.Oct 29 2017, 1:42 PM

A hacky way to do it is maybe to create fake "sites" per languages. We would for example have amiincubatorwiki would be a fake site that could be used for sitelink that have exactly the same configuration as the one of incubatorwiki

@daniel @hoo what's your thinking about @Tpt's suggestion?

Liuxinyu970226 added a subscriber: Superchilum.
Liuxinyu970226 added a subscriber: Sannita.

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.

Well, it could be set true for any wiki known to have permanent duplicated pages, such as Judeo-Spanish (Ladino) Wikipedia, where we have lad-Latn and lad-Hebr pages in parallel.

I'm of the opinion, that it's not our role of Wikidata to create pseudo-fake websites. In most of the relevant cases it would make sense to actually have real websites.

The langcom policy that prevents the creation of those sites is the core problem and a meta RfC to change it would be the best way forward. C933103 already started a draft for the RfC.

As far as mul.ws goes, can you point to examples where we have Wikidata items that would want to multiple pages on mul.ws?

gh87 removed a subscriber: gh87.Dec 15 2017, 10:19 PM
Koavf added a comment.EditedDec 16 2017, 2:05 AM

pseudo-fake websites

Why is this? Does the proposed solution above that allows multiple values for *only* these three projects sound acceptable to you?

As far as mul.ws goes, can you point to examples where we have Wikidata items that would want to multiple pages on mul.ws?

Why would mul.ws be different than any other version? E.g. Do we only want to link the Latin editions of the Bible with the French ones but *not* the Javanese one?

I'm of the opinion, that it's not our role of Wikidata to create pseudo-fake websites. In most of the relevant cases it would make sense to actually have real websites.

The langcom policy that prevents the creation of those sites is the core problem and a meta RfC to change it would be the best way forward

What an outrageously nonsensical comment. The fact that these test-projects are on Incubator, BetaWV or OldWS shows that they are in the process of getting their own subdomains. The solution is not to just indiscriminately create a ton of inactive new wikis, but to make it easier for people to be active on Incubator etc.

What an outrageously nonsensical comment.

The comment makes sense (although one may disagree with it), and is more polite than your reply.

@Samwilson, @ChristianKl and @MF-Warburg : If you are a "pure Wikidata"-type person, this comment probably made sense. The comment made no sense whatsoever in the broader context of the history of project creation and approvals across the WMF project universe. There are reasons that we don't just create those sites, even if that should happen to be inconvenient for Wikidata.

Ouch everyone. Merry Christmas to you all.

The issue we have is a clash of technical nature

  1. We have small languages put together on one wiki as it is easier/resource-wise to manage (WMF management)
  2. Wikidata only allows one site link per wiki. (WD data mgt)

I didn't see that the proposal was to create the wikis, I saw the proposal into "tricking" wikidata, or mediawiki interwiki map to have an Asturian (ast:) work at mul.wikisource to be linkable by ast:(Title of work) or mul:(Title of work). Perform the tricks at WD, perform it through moving files into specific paths, perform it be server path rewrites, whatever.

This is not about wikidata, so to speak, it is about giving these smaller represented languages the ability to have their works presented and linked. Wikidata is seen as the means to run queries, to search, to present metadata, and these small communities need someone to assist them to a resolution, not a lot of people just saying "no, too hard" and then moving back to the shiny toys, whatever, after all these years, we just would like a practical working solution.

That was well-said, @Billinghurst . Thank you.