[Goal] Sitelinks and arbitrary accesses 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
T206426: Storing multiple sitelinks to a multilingual wiki
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
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 wikis.

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.

Liuxinyu970226 added a comment.EditedFeb 18 2018, 8:13 AM

that it's not our role of Wikidata to create pseudo-fake websites

If you say a likely sentence with just modifying Wikidata to CLDR or other Unicode products, to Unicode staffs, that can result you to be prosecuted by em, as you insulted the vision of Unicode. Meanwile, no one wanna create sites with only long time unmaintained bones.

to actually have real websites

[criteria?]

a clash of technical nature

I would say, however, that this should be a good design reborn rather than a negative clash.

Wikidata only allows one site link per wiki. (WD data mgt)

That's just a damn limit that if I'm Daniel, then I would oppose that BEFORE the launching of Wikidata.

the proposal into "tricking" wikidata

Tricking means to create things that not even wrong, compare with the Wishlist Survey comments, this is however a new era for establish AI interfaces, that same topics' pages with just scripts, spelling, server databases, and/or clusters can sync knowledges without help of bots, which can be killed when maintainers died.

interwiki map to have an Asturian (ast:) ... be linkable by ast:(Title of work) or mul:(Title of work).

(and else?!) No need to, see T54971#3570164 above.

Finally, Синь Нянь Куай Лэ

Koavf added a comment.Feb 18 2018, 8:28 AM

If necessary, we may need to disengage the proposal for mul.ws from the two incubators. Again, mul.ws is a permanent home for some works and unlike incubator and beta.wv, some works will stay there permanently. There will never be a Volapük Wikisource--the corpus of texts is too small and there is no chance of language revival for it or a huge influx of original translations into it. mul.ws does not use multiple subdirectories as on Incubator, so it's not like two pages are going to have the same title but they are just in different test projects like /Wy/qqq/foo and /Wq/qqq/foo or something.

Liuxinyu970226 added a comment.EditedFeb 18 2018, 8:55 AM

Anyhow, I now want to modify Help:FAQ to reflect this problem:

  1. There is an item that already has a Wikipedia sitelink in language X. I want to add a second sitelink to the item for another Wikipedia article in language X that fits as well but it won't let me. What should I do? Wikidata allows only one sitelink per item per language. You will see an error message when attempting to add a new sitelink to a item page if that link has already been added to another item page. For more information, see Help:Sitelinks.

...Wikidata (+currently) allows only one sitelink per item per language...

  1. I tried to add a sitelink to an item, but when I tried to save it I received an error message. What should I do? Wikidata allows one sitelink per item per language. If you receive an error message but believe the item you are editing is the most appropriate one for the sitelink, you may need to merge two items. Please consult Help:Merge or visit Wikidata:Interwiki conflicts to report a conflict.

per above

  1. When will Wikidata be integrated with Old Wikisource/Wiktionary? There is currently no progress towards integration with most Wiktionaries, so no date can be offered. The challenges of Wiktionary integration have hit major snags, in part because the data structure of the Wiktionaries does not match that used by Wikidata. An introduction of existing sister project links into all local wikis is planned. The ticket for it is phabricator:T103102. There is no timeline for it yet. See our weekly summaries for status updates (they are also sent out to the Wikidata-l mailing list).

When will Wikidata be integrated with Beta Wikiversity/Old Wikisource/Incubator and else?
First phase of integration of Wiktionaries are done, so non-main namespaces' pages are linkable as same ways before. We implememted the Cognate extension to main namespace pages and thus their interwiki links are machine-handlable. The second phase is stucked on T175273, it's only deployed on English Wiktionary as tentative. The challange of deploying on three sites which are testing new language editons is drafting on T54971, but also no timeline for those yet. See our...

jhsoby added a subscriber: jhsoby.Aug 4 2018, 10:55 PM
Liuxinyu970226 renamed this task from [Goal] Sitelinks to Incubator, OldWikisource and BetaWikiversity to [Goal] Sitelinks and arbitrary accesses to Incubator, OldWikisource and BetaWikiversity.

I am test admin in Khowar Wikipedia incubator project, I am facing errors in Module, Template and wikidata, can anybody fix these errors?

mostly of the Templates, Modules has been fixed by Liuxinyu970226, thanks for that, except for those which includes "attempt to index field 'wikibase' (a nil value)" (which we are still waiting for Wikidata supports). can anybody fix the wikidata supports for Khowar Language. thanks

Ok with T202543 being resolved we can now do the same for incubator and enable arbitrary access there if someone wants to open a ticket for it.

So you just tell me that for those three wikis, only arbitrary accesses are possible? Let us withdraw sitelinks support requests?

It's the next step. Once we have that let's see what we can do about sitelinks.

I'd still love to see that why T206426 can't be the answer of "what we can do about sitelinks".

  1. @Liuxinyu970226: Let's do this one first, please. Will you put in the ticket?
  2. The more experience I have on Incubator, the less I'm so sure I want sitelinks (other than in the Incubator: and Help: namespaces). There are some tests that are pretty well developed and pretty well maintained, and sitelinks to them would be fine. But there are also plenty of tests on Incubator where the content is really trivial, and I'm not sure sitelinks to them are so useful. Maybe better to wait until some version of @Amire80's project (T165585) is done and then link selectively to well-maintained incubation subdomains only.
Liuxinyu970226 added a comment.EditedNov 10 2018, 7:02 AM

To answer the first question, I've filed T209207 and T209208.

For second, well, linking them are also useful even long unmaintained, see Template:Cite web (Q5637226) for example, there are nearly 60% editions that last edit histories are 2017 and before, while 35% out of them are even ~2009, but how do Wikidata users removed them just because unmaintained? Anyway if the technical block mentioned on T206426 fixed, we can setup a subpolicy within Incubator that which kind of pages can be WD-linked, and which are not.

Mahagaja removed a subscriber: Mahagaja.Thu, Nov 15, 7:57 PM