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.

In T54971#3569662, @Bugreporter wrote:

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)

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.

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

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?

In T54971#3719110, @Lydia_Pintscher wrote:

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

The suggestion is summaried at https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Wikidata/Allow_multiple_entry_from_same_site_on_wikidata by @C933103 , got 11 supports and 3 opposes

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?

In T54971#3841692, @ChristianKl wrote:

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?

In T54971#3841692, @ChristianKl wrote:

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.

In T54971#3844679, @MF-Warburg wrote:

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.

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, Синь Нянь Куай Лэ

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.

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

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

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

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

mentioned at https://www.wikidata.org/wiki/Help:Handling_sitelinks_overlapping_multiple_items#Discuss_the_solutions

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.

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.

I'm really not sure about Wikisource and Wikiversity, but for Wikipedia, Wikivoyage, and other such projects, the better solution is to have separate sites per language, as I suggest in T165585.

beta.wv shouldn't exist--it's entirely redundant to Incubator. mul.ws actually hosts some multilingual works which makes it inherently different from any other WMF project. Some things will never "graduate" from mul.ws to a new domain so we need to have a method to link to it.

@Amire80 But some Wikipedias also have reasons (e.g. multi-scripts used, and FWIW MediaWiki-Language-converter can't work for at least Min Dong, Hakka, Ladino and (through can work "remotely") Mongolian) and benefits to 1. show same "list of language editions" for two or three pages, that no differents other than scripts; 2. query same statements for those affected pages; 3. (if even possible) provide same visitor statistics; 4. (please @Shizhao do not add Chinese-Sites just because of my sentences here) finally deprecate Template:Incubator for them, at least on zhwiki.

In T54971#4823687, @Liuxinyu970226 wrote:

@Amire80 But some Wikipedias also have reasons (e.g. multi-scripts used, and FWIW MediaWiki-Language-converter can't work for at least Min Dong, Hakka, Ladino and (through can work "remotely") Mongolian) and benefits to 1. show same "list of language editions" for two or three pages, that no differents other than scripts; 2. query same statements for those affected pages; 3. (if even possible) provide same visitor statistics; 4. (please @Shizhao do not add Chinese-Sites just because of my sentences here) finally deprecate Template:Incubator for them, at least on zhwiki.

This is a distinct issue. I am aware of it and I hope to address it inside ULS itself, although it will require some research and planning.

In T54971#3718220, @Tpt wrote:

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

Pushing this little bit up. More straight forward would be just to create domains for ''fake'' sites which would give HTTP 301 PERMANENTLY MOVED response.

Example

https://smn.w.incubator.wikimedia.org/wiki/Wp/smn/Oulu -> https://incubator.wikimedia.org/wiki/Wp/smn/Oulu

Bigger question is that if there is multiple languagelinks to single site then where else it needs to be configured? To sitematrix mostlikely? Also if there is multiple domains for single wiki linked in wikidata then how wikidata updates are propagated in this case.

I think we can remove OldWikisource from this task as concepts from this task that apply to it are now adequately covered by:

• T138332: Interwiki links to/from Multilingual Wikisource
• T206426: Storing multiple sitelinks to a multilingual wiki

This task can now focus on just Incubator and BetaWikiversity.

I am against adding functionality to Wikidata to accomplish T206426, short of adding sitelink link prefixing a la Special:MyLanguage/. See my comments on that task.

Since Multilingual Wikisource is considerably different than Incubator and BetaWikiversity (its content never matures to migrate to a different wiki like them), it should be covered by a different task: T138332

As for this task, I am against introducing WD sitelinks for Incubator and BetaWikiversity due to their inherently temporal nature but that can continue to be hashed out here (I am certainly not the only nor even the most informed/important voice in such matters).