Module talk:Wikidata label

getLabelByLang

For optimal caching, the module shouldn't use mw.wikibase.getLabelByLang (by default). There is an explicit note about this in the documentation:

Note: This should not be used to get the label in the user's language on multilingual wikis, use mw.wikibase.getLabel for that if by any means possible.

This can cause weird bugs on pages with {{Label}}, {{Q}} etc. (original report). --Matěj Suchánek (talk) 09:18, 28 March 2020 (UTC)

Matěj I am sorry I did not see your note earlier. The problem with using mw.wikibase.getLabel is that it is hard to test that the module works properly if you can not predict what the module supposed to return. I am working now in fixing issues with Module:DateI18n but I will think about your suggestion. Also one of the big uses of the module (al least on Commons) is by other modules and they always pass the language. --Jarekt (talk) 03:00, 10 April 2020 (UTC)

(I fixed a mistake in my comment.) I understand your concern. Anyway, while providing the language really should query for the appropriate label, I see no problem in using getLabel/getLabelWithLang when it is not provided (this just needs to be documented). Ideally, templates and modules wouldn't use the {{int:lang}} hack. --Matěj Suchánek (talk) 08:34, 10 April 2020 (UTC)

Why can't you predict it? I assume this is for writing module unit tests. We do not really care what is in the test vector values exactly. We can just generate the test vectors by fetching something from Wikibase and then compare the modules output to see if it is the same. Doing that also protects against changes in the Wikibase database data (so you do not have to update your test vectors anytime anyone changes a value on WD, SDC, etc.). As an example, I converted the commons sandbox test vectors to generated ones vs. the human created static ones that were there before: c:Module:Wikidata label/sandbox/testcases. —Uzume (talk) 19:12, 20 April 2020 (UTC)

The bigger problem I see is that the |lang= parameter to getLabel specifies more than just the lingusitc label fetched from an item entity but also the language specific sitelink for monolingual project sites. If we move to mw.wikibase.getLabelWithLang (if you look at the code mw.wikibase.getLabel and its backwards compatible alias mw.wikibase.label call mw.wikibase.getLabelWithLang and just throw away the returned language code so there is no disadvantage to calling the former over the latter), we cannot specify the language of the label. That seems wrong if we are generating language specific sitelinks. The way I see it, the only way to do that would be to do away with |lang= altogether and have the sitelinks also follow the same language fallbacks. On the other hand, I always found this module's use of sitelinks and labels strange. Typically when using a sitelink the link label is the same as the sitelink—not the Wikidata label (these can be significally different for good reasons; page names must be unique within a project site and that is not true for WD labels and there are other restrictions on page names as well). —Uzume (talk) 19:12, 20 April 2020 (UTC)

I think that if language is not specified one can call label, lang = mw.wikibase.getLabelWithLang(item), keep the label to show as label and use |lang= to pick the sitelink (if link=Wikipedia). --Jarekt (talk) 23:55, 20 April 2020 (UTC)

Adaptation for Schemas

Tracked in Phabricator
Task T225924

Schemas do not seem to be covered by the module yet, which makes things like {{EntitySchema}} look weird, e.g. as per E25. --Daniel Mietchen (talk) 23:24, 8 April 2020 (UTC)

Pinging Jarekt as maintainer. --Daniel Mietchen (talk) 22:40, 9 April 2020 (UTC)

I do not know much about schemas. I do not think it is supported by mw.wikibase.getEntity function yet. Does anybody know if there is a way for lua to talk to it? --Jarekt (talk) 03:16, 10 April 2020 (UTC)

Seems not outside Wikidata. But it reminds me of a hack used years ago before data access was possible: mw.text.jsonDecode( mw.title.new( 'EntitySchema:E1' ):getContent() ).labels.en. --Matěj Suchánek (talk) 08:39, 10 April 2020 (UTC)

When a MW extension adds a new Wikibase entity type it should provide its own Scribunto access, e.g.:

• WikibaseLexeme:/src/MediaWiki/Scribunto/mw.wikibase.lexeme.lua
• WikibaseMediaInfo:/src/DataAccess/Scribunto/mw.wikibase.mediainfo.lua

I do not see anything like that in mw:Extension:EntitySchema. It is easy to search for all such Scribunto lua support files in MW extensions (at least in MW repos) with a code search like: https://codesearch.wmflabs.org/extensions/?q=mw%5B.%5Dwikibase&i=nope&files=.*%5B.%5Dlua&repos=

So while Wikidata is supporting EntitySchema entities just fine, there is no real Scribunto lua support for such and anything that works there is just by default (because of Wikibase Scribunto support and PHP support for the new entity in MW itself). —Uzume (talk) 17:53, 20 April 2020 (UTC)

See Phabricator:T225924 ticket. --Jarekt (talk) 23:46, 20 April 2020 (UTC)

Recent change to module

I have been using Template:Q in lists of pages, and checking Special:RecentChangesLinked for changes, but it now links to (for example) Special:EntityPage/Q4729454 instead of Q4729454 so changes to the item do not appear, and this seems to be because of a recent change to this module. I could just link to the item but there would be no label; is there a way of using Template:Q to link directly to the item, or an alternative that can be used? Peter James (talk) 23:26, 15 May 2020 (UTC)

Also because of this change there is no link to an item from discussion where it is mentioned. Peter James (talk) 12:15, 16 May 2020 (UTC)

And the template now shows blue links for pages that have been deleted (Q94061227, Q94061227). Peter James (talk) 12:30, 16 May 2020 (UTC)

The difference is because the new links are interwiki links to d:Special:EntityPage vs. direct local ones (there are also external links, e.g., mw.wikibase.getEntityUrl returns an external link to https://www.wikidata.org/wiki/Special:EntityPage). The functionality Peter James is interested in will never work from any wiki other than Wikidata. To restore the behavior, first requires direct linking to each entity page which varies by entity type due to the different prefixes. This requires the module to be updated and kept synchronized each time another/different entity type is added/supported. For example, on Wikidata we need "" for items, "Property:" for properties, "Lexeme:" for lexeme and "EntitySchema:" for entity schema, etc.; and for Commons we could determine titles from MediaInfo entity ids by using the expensive mw.title.new with the page id parameter by removing the "M" prefix and then direct linking that way instead of the older method of linking to c:Special:Redirect/page/... or the newer method of linking to c:Special:EntityPage/M... I recommend retaining linking to interwiki linked Special:EntityPage and only attempting to restore the local link behavior when the local wiki matches the interwiki prefix (i.e, if the module is running on Wikidata use local Wikidata title linking heuristics and if it is on Commons use local Commons title linking heuristics, etc.). That requires detecting which wiki the module is running on of course. As far as I know, in general, there are no true methods for determining entity titles remotely (e.g., there is no method to remotely determine a MediaInfo title). We only have our existing heuristics. Similarly, there is no true method for remotely linking to talk page of a wikibase entity (yes, we could local link to a MediaInfo talk page but there is no way to remote link to such; luckily "File talk:" is not used much). This is why I personally recommend against directly supporting such behavior in the module and am not sure it is a good thing to use the likes of {{Q}} in something like a watch list anyway. Perhaps a good compromise would be to have the module detect local linking possibilities and use a submodule to handle local linking heuristics (in a manner similar to how language localization in done in many modules) and always fallback to support external interwiki linking. —Uzume (talk) 10:24, 20 June 2020 (UTC)

Not only in watchlists (where it would require the addition of a direct link alongside the Q link) - EntityPage links are also missing from Special:WhatLinksHere which is the place to look for discussion of an item. There is an alternative (Special:Search, select "Advanced" then "All" and deselect entity namespaces and the file namespace) but that is less convenient and if people don't know about this they may just assume there has been no discussion. Peter James (talk) 17:36, 20 June 2020 (UTC)

@Peter James: I do not mean to be insulting but I really do not understand your response above. Wikibase and thus Wikidata entities have essentially three parts: an abstract entity URI meant to refer to the entity itself, a data part that is data about the entity (based on the stored Javascript), a page part which is like the data part but targeted for human consumption vs. machine so it it usually HTML-based and has edit interfaces. The EntityPage part is the part most people think of and it is normally represented in Special:WhatLinksHere. I do not really consider Special:WhatLinksHere as a place for any discussion (though it does only track local links and not interwiki or external links). I am not sure what you are trying to say about Special:Search. It has many good features (see mw:Help:CirrusSearch; I particularly like "insource:"). On Wikidata and Commons (which use mw:Extension:WikibaseCirrusSearch) it also can search with things like "haswbstatement:", see mw:Help:Extension:WikibaseCirrusSearch. —Uzume (talk) 05:40, 21 June 2020 (UTC)

The fact that this module ever worked the way you are interested in has always been accidental as it has always used interwiki links but they were not originally via the Special:EntityPage redirector. Typically interwiki links are not tracked as local links, however, it seems Mediawiki makes some special optimization for interwiki links that directly refer back to itself (e.g., "d:" prefixed links on Wikidata and "c:" prefixed on Commons, etc.). This can be evidenced by links like the following: d:Q94061227 vs. c:d:Q94061227 —Uzume (talk) 05:53, 21 June 2020 (UTC)

Ok, I will look into restoring the old style of linking. It was a suggested change aimed at simplifying the code, but I guess it breaks things. --Jarekt (talk) 03:20, 17 May 2020 (UTC)

Peter James, I restored the old style links. --Jarekt (talk) 03:36, 23 May 2020 (UTC)

Escaping

Per Template talk:Q#Bug when label includes wikicode, labels should be escaped (mw.text.nowiki) when printed to the wikitext. However, if another module requests a label from this module, it shouldn't be escaped here. --Matěj Suchánek (talk) 11:37, 8 November 2020 (UTC)

 Done This was fixed at the source by c:Special:Diff/524477781/prev and locally by Special:Diff/1336321084/prev. Escaping is always performed but further markup can be applied around the output. —Uzume (talk) 03:53, 7 January 2021 (UTC)

Replacing Module:No globals

{{Editprotected}}

Please replace require('Module:No globals') with require('strict'). Legoktm (talk) 05:49, 5 November 2022 (UTC)

 Done --Matěj Suchánek (talk) 11:18, 5 November 2022 (UTC)

Make getLink public

{{Editprotected}}

I would like to use the getLink function of this module for {{Wikipedia}}, could you please:

Change

local function getLink(link_type, item, entity, langList)

to

function p.getLink(link_type, item, entity, langList)

(and the only call to the function in line 308 to p.getLink)?

--Push-f (talk) 07:24, 23 November 2022 (UTC)

That has not worked --Ameisenigel (talk) 22:21, 2 December 2022 (UTC)

@Push-f, Ameisenigel: please test your code in Module:Wikidata label/sandbox before deploying anything. You shouldn't be deploying untested code. Multichill (talk) 22:24, 2 December 2022 (UTC)