Module talk:Wikidata label

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Relation with Module:Wikidata/FormatEntity[edit]

Apparently, this module is essentially Module:Wikidata/FormatEntity. It may be a good idea, to have a more lightweight module than Module:Wikidata to use Wikidata data, though I think the performance impact will be very minor. In that case, we should probably get rid of Module:Wikidata/Format entity though and always use Module:Wikidata label instead. --Zolo (talk) 19:58, 23 September 2016 (UTC)[reply]

This is a result of this discussion. The performance impact was huge, since Module:Wikidata was causing some infinite loop with the way frame was used. I agree that it should be merged with Module:Wikidata/FormatEntity. --Jarekt (talk) 20:46, 23 September 2016 (UTC)[reply]
Ok, I thought that was just to avoid loading a big module. Do you have the correct link to the discussion. I got notified of it at the start, but lost the notification and was totally unable to find the discussion again... -Zolo (talk) 06:34, 24 September 2016 (UTC)[reply]
Sorry about the bad link. I fixed it now. --Jarekt (talk) 02:32, 25 September 2016 (UTC)[reply]

Performance[edit]

Tracked in Phabricator
Task T142903
The performance is not so good: use it to extract about 100 labels on a page, you'll be very near of exhausting memory/time resources on the server.
When geolocalization templates were converted to use Wikidata as a source, the resources used by this module have exploded.
In my opinion, geolocalization templates should better be locally cached and hosted on Commons directly, as they were before, possibly with helps of bots to import updated data from Wikidata.
Please profile it, and see what is the most costly here, we really need optimizations (and I fear that the execution time is also impacted by retreiving the full dataset of a Qnnn entry, when we just need the label. In highly populated elements (such as Germany) it takes about one half second (five to ten times more than the time take for elements with lower amounts of information: less wikipedia links, less translations...) but still largely excessive.
Just an example
view the page Template:Germany and see the resources used just to display the label "Germany" (more than 320ms per returned label for a requested language). Note that this module uses a scanning loop to search for fallbacks, but isn't there any way to get specific properties from wikidata elements instead of the full data set ? (the main problem is in mw.wikibase.getEntity(item): there's no filter at all for the properties we really need, they are all retrieved, parsed, indexed, and this uses too much memory and time).
verdy_p (talk) 23:38, 8 October 2016 (UTC)[reply]
Unlike Module:Wikidata this module was designed to be lightweight and fast, but if there are ways to write it better or faster, I am open for suggestions. If the problem is with calling Wikidata in general than a better place to discuss it might be on phabricator. That way it has a chance to be seen by people that can change anything. --Jarekt (talk) 18:49, 10 October 2016 (UTC)impr[reply]
That's phabricator:T142903. Except squashing bugs like infinite loops, it seems that anything we can do here has negligible performance impact compared to that. --Zolo (talk) 09:17, 12 October 2016 (UTC)[reply]
Negligible impact ? Look again at Germany (and compare to Montenegro) and it is really evident thant the problem is that you are using the "mw.wikdiata.getentity("Qnnn")" to retrieve the FULL entity (all its claimed properties), when in fact you are just interested in very specific properties (only the names of entities, and optionally the wikipedia links). This means that you are spending much time parsing gentiles, populations, presidents, shared borders, administrative subdivisions, formal long names, diplomatic relations...)
There's definitely a problem. The Wikidata request must be more selective. This causes unnecessary work on the server (notably in execution time, which is the most visible, but as well on the huge amount of memory used). Something must be done on the Wikidata module to allow such selection. If you can't implement such property filters due to the current impementation of the builtin Wikidata query module integrated in MediaWiki, I strongly suggest it to be developed added to the API (note that even when looking at the element "Germany" in Wikidata, it now takes a very long time, here also the UI should be improved to not load all data at once, but load them on demand (only the list of properties would be loaded, even the list of Wikipedia links would be retrieved on demand.
Adding filters in Wikidata requests (and probably some better system for caching data) is now becoming a real need for long term, otherwise Wikidata will no longer be usable and wiki pages using data from Wikidata will start seeing many pages exploding. verdy_p (talk) 19:14, 13 October 2016 (UTC)[reply]
To get a Wikipedia link from the Germany item, we need to load the full Germany item, and that will be so until T142903 is solved. There is nothing we can do on the module about it (well I think someone once found a Javascript workaround or something, but I don't think that's really recommened either). -Zolo (talk) 07:58, 14 October 2016 (UTC)[reply]

Additional note : mw:Extension:Wikibase Client/Lua explcitly says that wikibase.getEntity( id ) is expensive when used on an entity not connected to the current page. What it does not says is that it is also expensive for the singel entity associated to the current page (see some Wikipedia page about Germany, where it is used implicitly (at least to show the wikipedia links), it it takes a avery significant time on the total time to render the page (you can test it as well by creating an empty page "Germany" on some very small wiki which still does not have one, or looking at one that has almost no content, and no complex templates, just a few sentences, some categories, a few links, and a few images for the map and the national flag.

Ideally we should be able to be more specific than just wikibase.getEntity( id ), using some filters (with some query flags), for example to get only label names, and some designated properties (only Wikipedia links if they are requested, plus probably the flag for getting only the prefered claims, to eliminate more claims). There are probably things to develop outside the Lua client interface, on the server side, to support such filters. verdy_p (talk) 20:12, 13 October 2016 (UTC)[reply]

Improvment[edit]

You could improve link=commons, by also checking P373(commons category) then P935(commons gallery).
Between line 40 and 41, you could check P373(commons category) then P935(commons gallery). Best regards Liné1 (talk) 14:07, 12 May 2017 (UTC)[reply]

 Agree. I will look into it. So far this module was used mostly in "link=Wikipedia" mode, so I did not care about well working "link=commons" mode. But if there is a need, I will improve it. --Jarekt (talk) 18:28, 12 May 2017 (UTC)[reply]
✓ Done --Jarekt (talk) 03:28, 14 May 2017 (UTC)[reply]
Excellent! Thanks a lot. Liné1 (talk) 06:13, 16 May 2017 (UTC)[reply]

Using mw.wikibase.label and mw.wikibase.sitelink functions to prevent loading of the whole entity[edit]

Tracked in Phabricator
Task T173194

I just deployed rewrite of this module to minimize the need for loading of the whole entity while calling {{Label}}. Pleas let me know if there are any issues. --Jarekt (talk) 12:32, 12 October 2017 (UTC)[reply]

@Jarekt: There is a really strange behaviour. Run this in your Lua console:
= require('Module:Wikidata label')._getLabel('Q123', 'en')
= require('Module:Wikidata label')._getLabel('Q321', 'en')

This is what you obtain: 

[[w:en:September|September]]
[[w:en:September|Milky Way]]

It seems like a bug in a static cache. --Valerio Bozzolan (talk) 19:38, 22 October 2017 (UTC)[reply]

Yes this is bizarre. It must be something about mw.wikibase.sitelink function, since the second call does not know anything about Q123, so the only data passed to it must have been cached. --Jarekt (talk) 13:29, 23 October 2017 (UTC)[reply]

As I said in phabricator:T173194, I corrected the issue and rolled out the new version again. Pleas let me know if there are any other issues. --Jarekt (talk) 13:42, 24 October 2017 (UTC)[reply]

Unnecessary “w:” prefix in Wikipedia links[edit]

The module currently displays Douglas Adams as [[w:en:Douglas Adams|Douglas Adams]] (using English interface language, similar using others), which means an extra redirect (even cross-domain if the target is not the English Wikipedia). Is there any language code which links to the appropriate language Wikipedia on enwiki, but not in Commons? If not, it could be changed to [[:en:Douglas Adams|Douglas Adams]]. —Tacsipacsi (talk) 09:11, 19 May 2018 (UTC)[reply]

Tacsipacsi, to me [[w:en:Douglas Adams|Douglas Adams]] and [[:en:Douglas Adams|Douglas Adams]] are exactly identical so there is no preference of one over the other one. I picked one with "w:" because I noticed others were copying some of my modules to other wikis and that way the link will work the same way no matter what wiki you run it from. Can you explain again why you prefer the one without "w:"? --Jarekt (talk) 02:00, 20 May 2018 (UTC)[reply]
For example, w:de:Wikipedia:Hauptseite links to https://en.wikipedia.org/wiki/de:Wikipedia:Hauptseite, so when I click on it, the browser loads one more page (redirecting to https://de.wikipedia.org/wiki/Wikipedia:Hauptseite) which it wouldn’t load if the w: prefix wasn’t there. It’s not a huge amount of data, but may be important if one has limited data pack. It can also be embarrassing if someone highlights the links pointing to their own language Wikipedia, or just because it’s not marked as visited if I have opened the page from somewhere else (I noticed the use of the prefix because of the latter). I also think that this module is only useful in its current form on multilingual wikis, which, as far as I know, all use Wikipedia for language prefixes. On the French Wikisource, I wouldn’t try to link to the English Wikipedia. I would start with frwikisource, and if that doesn’t exist, I would go on with French Wikipedia. If that doesn’t exist either, I would stop trying. –Tacsipacsi (talk) 07:42, 20 May 2018 (UTC)[reply]
For Wikipedia, [[:{{BaseLang}}:link]] does seem to work well (that's what's used in {{Wikidata Infobox}}, then [[:wikiquote:{{BaseLang}}:link]] for other wikis. English is a special case, but it does make a difference for other languages. Thanks. Mike Peel (talk) 11:13, 20 May 2018 (UTC)[reply]

Suggestion for performance improvement[edit]

Hi, I just looked at this module again and I have two suggestions for improval:

This would result in the following snippet: 

	-- get label (visible part of the link)
	if (userLang == lang) and (not entity) then -- call if requesting label in user's language, but skip if we already have entity
		label, language = mw.wikibase.getLabelWithLang( item ) -- prefered way of calling that do es not need to load entire entity
	else
	-- hard way to get label by querying all the languages on the langList
	-- used if requesting label in language different than user's, or if we already have entity
		for _, language in ipairs(langList) do         -- loop over language fallback list
			-- look for label in the specific language
			if entity then
				label = entity:getLabel(language)
			else
				label = mw.wikibase.getLabelByLang(item, language)
			end
			if label then break end                    -- label found and we are done
		end
	end

@Jarekt and Multichill: -- Hoo man (talk) 13:49, 14 June 2018 (UTC)[reply]

Hoo man, thanks for leting us know about mw.wikibase.getLabelByLang. I think we can get the code even simpler. Your 

	for _, language in ipairs(langList) do  -- loop over language fallback list looking for label in the specific language
		if entity then
			label = entity:getLabel(language)
		else
			label = mw.wikibase.getLabelByLang(item, language)
		end
		if label then break end                    -- label found and we are done
	end

would work just fine instead of calling getLabelWithLang. --Jarekt (talk) 14:52, 14 June 2018 (UTC)[reply]

lang is not optional in reality[edit]

=p._getLabel('Q1')

on the Lua console gives:

Lua error at line 53: bad argument #1 to 'lower' (string expected, got nil).

Backtrace:

  1. [C]: in function "lower"
  2. Module:Wikidata_label:53: in function "_getLabel"
  3. console input:7: ?
  4. [C]: ?
=p._getLabel('Q1', '')

gives:

[[d:Q1|Q1]]

=p._getLabel('Q1', 'en')

gives:

[[w:en:Universe|Universe]]

Only the last one is correct, all three should give that. —Tacsipacsi (talk) 19:39, 18 October 2018 (UTC)[reply]

Syntax of _getLabel is p._getLabel(item, lang, link_type, capitalization, show_id), none of the parameters are optional, and the code was not tested for the case where they are missing. They are all optional in getLabel function. --Jarekt (talk) 17:16, 22 May 2019 (UTC)[reply]

Try to link to commonscat[edit]

@Jarekt: I've added an option in the sandbox version (diff) to try to link to the Commons category if possible (trying P373, then falling back to sitelink, then P935 gallery). Code seems to work, and passes existing tests. If all is okay, I'd be grateful if you would consider it for the live branch. Jheald (talk) 16:56, 22 May 2019 (UTC)[reply]

Jheald I would just add sitelink check to the current version. It would be much simpler. I thought there was a process to copy P373->siteling and sitelink->P373 if one of them are missing. That is why I did not check the sitelink. --Jarekt (talk) 17:22, 22 May 2019 (UTC)[reply]
@Jarekt: Sitelinks don't necessarily point to Commons categories, sometimes they link to galleries. That's why I would prefer the 'commonscat' option to follow a P373 if possible. Jheald (talk) 17:50, 22 May 2019 (UTC)[reply]
Jheald When I wrote this function I checked that each item with sitelink to commons category or gallery also had P373 and/or P935. In such a case your commonscat option would return always the same result as commons option. If that is no longer the case, than we can copy those links, or replace my commons option with your commonscat option. --Jarekt (talk) 18:08, 22 May 2019 (UTC)[reply]
@Jarekt: I'm sorry, I'm not understanding you. If a Qid is sitelinked to a gallery, then eg {{label|Q18|link=commons}} -> South America.
But I want the link to point to a category. {{#invoke:Wikidata label/sandbox|getLabel |item=Q18 |link=commonscat}} -> South America. So it's different. Jheald (talk) 18:16, 22 May 2019 (UTC)[reply]
Jheald, You are right. I was misreading the code. I think I can make the your code more compact. Let me try. --Jarekt (talk) 18:20, 22 May 2019 (UTC)[reply]
How about the current code? --Jarekt (talk) 18:41, 22 May 2019 (UTC)[reply]
@Jarekt: Neater, looks good, and seems to work. Thanks! Jheald (talk) 22:12, 22 May 2019 (UTC)[reply]
✓ Done deployed --Jarekt (talk) 03:46, 23 May 2019 (UTC)[reply]

Lua error in Module:Wikidata_label at line 24: attempt to call method 'getSitelink' (a nil value).[edit]

I noticed today many files with "Lua error in Module:Wikidata_label at line 24: attempt to call method 'getSitelink' (a nil value)" error. See here. I do not think that is caused by any changes to any Lua modules. If anybody can figure out the reason please let me know. --Jarekt (talk) 04:46, 12 December 2019 (UTC)[reply]

I suspect that something has changed with structured data - pinging @Keegan (WMF): . Thanks. Mike Peel (talk) 12:30, 12 December 2019 (UTC)[reply]
A MediaInfo-specific Lua library got deployed recently (phab:T236692). It's pretty much a straight clone of the existing Wikibase library, but with some minor changes (see WIP mw:Extension:WikibaseMediaInfo/Lua). Essentially:
1. The getSitelink method - an unknown concept for MediaInfo entities - got removed
2. getCaption* aliases were added (in addition to keeping the getLabel* methods
It looks like this module's getSitelink function unconditionally calls entity:getSitelink when it has received an entity, but MediaInfo entities will now no longer have that method. Mmullie (WMF) (talk) 14:52, 12 December 2019 (UTC)[reply]
Mmullie (WMF), thanks for explanation, I will fix the module. --Jarekt (talk) 18:41, 12 December 2019 (UTC)[reply]
Fixed (?) with small tweak to the code to address immediate cause of the error. However this still does not make much sense as the entities the module was operating on were Wikidata entities and not SDC entieties. --Jarekt (talk) 19:08, 12 December 2019 (UTC)[reply]
I'm guessing that my change to delete the getSitelink method from MediaInfo entities, also causes it to disappear from the parent Wikibase entity class (that MediaInfo entities inherit from). I'm investigating, will keep you posted. Mmullie (WMF) (talk) 07:52, 13 December 2019 (UTC)[reply]

I think there is a similar problem in Module:Wikidata/Tools, example file: File:Paul Gauguin - Fatata te Miti (By the Sea) - Google Art Project.jpg. --Arnd (talk) 08:12, 14 December 2019 (UTC)[reply]

Arnd you are right, few other modules have exactly the same issue. Perhaps we should fix some, but lets let keep some as is for time being. Only about 200 files are affected as of today. And that way we can see if the issue was resolved, once there is some fix. --Jarekt (talk) 03:26, 15 December 2019 (UTC)[reply]

I just deployed a fix (essentially bringing back getSitelink as a no-op for MediaInfo entities, while making sure it doesn't affect Wikidata entities). AFAIK, that should fix these issues. If not, please comment on https://phabricator.wikimedia.org/T240563 Mmullie (WMF) (talk) 19:32, 16 December 2019 (UTC)[reply]

 Thank you. I just purged all the files in Category:Pages_with_script_errors and all the issues are resolved. --Jarekt (talk) 02:47, 17 December 2019 (UTC)[reply]

Structured data links seem broken[edit]

374042196 seems to be targeting some sort of support for linking to Commons:Structured data MediaInfo entities, however, they seem to use Special:Redirect/page for linking by local pageID. This has several issues. First, Module:Wikidata label seems to be intended to be ported to other sites and has been ported at least to Wikidata and such linking will not work correctly without specifying Commons in the link somehow (e.g., using an Interwiki prefix; so for starters put "c:" in front of "Special:Redirect/page/" in a manner similar to how "d:" is put in front of Wikidata entity links). Second, the identifier used is not specifically an entity ID but instead a generic pageID and these do not uniquely reference MediaInfo entities in Commons structured data (however, this seems to be a generic issue in how Commons structured data is created/organized so it probably is not an issue for this module to solve). For example: M2678663 vs. c:Special:EntityPage/M2678663. Even though one could attempt to filter nonexistent entity identifiers (e.g., trying to warn about the "holes" in MediaInfo identifiers when "bad" ones are used with something like mw.wikibase.entityExists), I recommend against this unless there is some way to do that at the link target (Wikidata or Commons).

I question if such SDC MediaInfo entity functionality belongs in a Scribunto Lua module named "Wikidata label" as these have nothing to do with Wikidata (though they do relate to Wikibase which does relates to Wikidata). And on that note, since adding this support code to the Scribunto module, the variable dLink is poorly named as it does not always link to Wikidata much less use the "d:" interwiki prefix. I suggest renaming this to eLink for "entity link" (vs. a Wikidata sitelink or a Commons property link). I also strongly recommend considering if this should be moved to a different module (pertinent to Commons structured data) or if this module should be renamed (to a name more pertinent to things beyond just Wikidata).

We should probably get one or more categories for Modules and Templates that use Wikidata and SDC. I notice there is Category:Wikidata modules (Q14564644) but it is not here on Commons. Until then for the SDC side of things we could add this module to this list: Commons:Structured data/Lua#Lua Modules accessing SDC.

For Wikibase entity links I would suggest linking via d:Special:EntityPage and c:Special:EntityPage instead of manually building the link (This is probably unavoidable for talk page links since they are not actual entity pages; I am not sure how you might link to the talk page of a MediaInfo entity since these are just "File talk" pages and there is no way to remotely refer to such a path by a subject pageID/MediaInfo entity ID). Since you are already in Lua, I would suggest mw.wikibase.getEntityUrl but is not remotely accessible and this not portable. It should work for any wiki with Wikibase Client installed and certainly works for entity types it knows about ("Q" and "P") however, ones supported by MW extensions only installed on the link target like MediaInfo and Lexeme likely will not work. Lexeme might work (or be able to work; the Lua interfaces are really new and still evolving considerably) since apparently all the WM wikis can access Wikidata information from Lua but I do not think one can get to Commons MediaInfo from wikis other than Commons right now (unlike Commons tabular and map data which is explicitly designed to be remotely accessible). I do not see usefulness in linking via c:Special:Redirect/page over c:Special:EntityPage (the only difference being if the "M" stays or not).

Also it might make sense to add support for other non-media types of Commons property links, e.g.:

There are also a large number of Commons media properties but I believe they are redundant for this module's purposes in light of SDC MediaInfo entities (which are sort of a canonical way to refer to Commons media from a Wikibase entity standpoint).

—Uzume (talk) 03:30, 9 January 2020 (UTC)[reply]

Uzume, Those are all great suggestions. About Special:EntityPage, I do not think I knew about that service when I was writing this module. I agree that it would be better to use it. The main use of the module is for Wikidata labels, the fact that it can also access SDC is less important. SDC captions serve quite different role and need different treatment, See Module:Information/sandbox's SDC_Description function. I am ok with changing internal variable names but I do nor want to change the Module name. I have done it before and it is impossible to track down all the places a module is used at, (try finding one of 13M pages Module:Date is used at). I was slowly rewriting a lot of my modules lately and there were some suggestions about improvements to this one on Wikidata. Once I am done with some other issues I will try to address them all. I also want to test if phabricator:T238484 is related to this module. Thanks for thoughtful analysis. --Jarekt (talk) 18:00, 17 April 2020 (UTC)[reply]
No, problem. I noticed some strangeness about this module and decided to study it and then I thought I would enumerate what I found to make sure I hadn't missed something and finally decided it could prove useful to others and decided to post about it (it might bring about useful change). Module:Information/sandbox (and its non-sandbox) seems poorly (or at least inefficiently) coded since all the functions call parseFrame which in turn always seems to call mw.wikibase.getEntity even though each call only appears to need a few fields (a label or claims for a single property). —Uzume (talk) 02:15, 19 April 2020 (UTC)[reply]

{{Edit request}}

Since you seem to approve, I worked up some changes in the sandbox here (see Special:Diff/380028543/412735647) and am requesting they be integrated (I only have TE on enwiki and not here on commons or I would integrate the changes myself). Note such changes are (minimumly) functionally different and required changes to the sandbox testcases: Special:Diff/412740463/prev. Similarly the non-sandbox testcases will have to be adapted to make them pass (they seem to be quite different from the sandbox ones). —Uzume (talk) 02:15, 19 April 2020 (UTC)[reply]
Uzume, ✓ Done, Thanks a lot. That is better. I added a few more changes I was thinking about. --Jarekt (talk) 03:15, 20 April 2020 (UTC)[reply]
I like how you extrapolated out the interwiki prefix for the target project and then built the link to Special:EntityPage, but the comment on the end of the line is now wrong. I have provided some comment changes here: Special:Diff/413279330/413323202. Thank you. —Uzume (talk) 13:10, 20 April 2020 (UTC)[reply]
As for your comments about Module:Information. The only functions calling parseFrame are the one which are only called from outside (usually templates). Those additional entries to the module are provided for testing and because they might be useful to other templates, but they are not called from Information template. --Jarekt (talk) 03:22, 20 April 2020 (UTC)[reply]
It is not just parseFrame. See my comments: Module talk:Information#Wikibase design issues. Most of my Wikibase design issues I mention there also apply here, e.g., _getLabel (where it accesses Commons category (P373) and Commons gallery (P935) claims) could be optimized to avoid fetching entire Wikibase entity structures. Sadly, the Wikibase API is still lacking in some areas and there currently is no method to similarly optimize _aliases as there is no method to access entity alias data short of pulling the entire entity structure but I like how the exported API functions here (allow but) do not require entity structures to be passed to them. —Uzume (talk) 13:10, 20 April 2020 (UTC)[reply]
When writing this module I was trying to avoid loading the whole entity if possible. Unfortunatelly it is sometimes not possible. --Jarekt (talk) 13:25, 20 April 2020 (UTC)[reply]

{{Edit request}}

I agree but the Wikibase API has improved over time and thus the potential for optimization has also improved. I made some Wikidata optimizations in the sandbox here that I would like to get integrated. See Special:Diff/413279330/413342690. Thank you. —Uzume (talk) 13:51, 20 April 2020 (UTC)[reply]
Uzume, That is great, but lets postpone this rollout. Each change to this module triggers refreshes of ~50M pages. So let it catch up. I would also like to address the issues mentioned on d:Module talk:Wikidata label. Right now the language is often provided by the template (it worked better that way a while ago). I would like to change it, so Lua code knows when user asks for specific language or we use en trick to access users language. If we are using users language than we should use mw.wikibase.getLabelWithLang instead of mw.wikibase.getLabelByLang. So we do label, lang = mw.wikibase.getLabelWithLang(item) instead of lang = frame:callParserFunction("int","lang"); mw.wikibase.getLabelByLang(item, lang) we are doing right now. Also There is something wrong with my unit testing, as I made some mistakes altering your corrections, which were not detected. I was experimenting with Module:ScribuntoUnit module, which seem to work better than Module:UnitTests, see Module:DateI18n/testcases. I would like to rewrite this module unit testing and possibly add more cases. --Jarekt (talk) 16:28, 20 April 2020 (UTC)[reply]
The changes were just optimizations and fixing a few comments. I am not in a hurry to get them integrated so long as they are queued to be such and not forgotten. Thank you. —Uzume (talk) 21:08, 20 April 2020 (UTC)[reply]

Kindly revert to the last stable version before yesterday's ill-advised changes. As it is, this error is now seriously affecting many Commons image files. The File description field is blanked altogether and replaced with this error message splashed in red:

Lua error in Module:Wikidata_label at line 52: Tried to write global yesno
—  JGHowes  talk 17:13, 20 April 2020 (UTC)[reply]
Can you provide an example? I have not been able to fine anything that transcludes this module in File namespace that has such an error. —Uzume (talk) 18:38, 20 April 2020 (UTC)[reply]
As examples: File:GIMS_2019,_Le_Grand-Saconnex_(GIMS0612).jpg and File:Randolph_Scott_and_Barry_Kelley_in_Buchanan_Rides_Alone.png  JGHowes  talk 19:34, 20 April 2020 (UTC)[reply]
I think you have a caching issue because I see no issues on either of those. Please try purging the page and/or doing a null edit on them before reporting such. The issue you are reporting was fixed in 413225403—about 30 minutes after the issue was introduced. Thank you. —Uzume (talk) 20:57, 20 April 2020 (UTC)[reply]
Thank you, Uzume. Indeed the malformed version was still cached at my end. Glad the issue was so quickly addressed.  JGHowes  talk 21:40, 20 April 2020 (UTC)[reply]

unit testing[edit]

I began new unit testing page at Module:Wikidata label/sandbox/testcases2. Anybody welcome to expand.--Jarekt (talk) 04:04, 21 April 2020 (UTC)[reply]

That is nice work. I like the generated test vectors. I would not have felt insulted if you had just overwritten and used Module:Wikidata label/sandbox/testcases instead of Module:Wikidata label/sandbox/testcases2. I notice some inconsistencies though. The first being that at the top you have local WL = require('Module:Wikidata label')-- the module to be tested and later you have things like self:assertSameResult(res, '{{#invoke:Wikidata label/sandbox|getLabel|item=Q36524|lang=en}}'). Notice the API function tests are not testing the sandbox module but the invoke function tests are testing the sandbox module. I will probably have to rectify this. It seems questionably to have template tests here in a module test suite: self:assertSameResult(res, '{{Q-|item=Q36524|lang=en}}'). Methinks that sort of testing should be in the tests for the template not the module, i.e, {{Label/testcases}}. One major reason for that is that this module is ported to other sites (e.g., WM projects) and the templates are not guaranteed to be named and implemented the same. That said, the testcases should be applicable to where ever the module is ported to so the testcases can be ported together. —Uzume (talk) 07:47, 22 April 2020 (UTC)[reply]
I fixed testcases2 to dynamically select the module to be tested based upon the invocation, however the results are now in failure. I am not sure what is going on but there might be something wrong with the sandbox. Compare:
I am thinking there should be a better way and perhaps we can pass the module to be tested in at the invocation point and then have a page with the results for both the deployed module and the sandbox module together —Uzume (talk) 10:52, 22 April 2020 (UTC)[reply]

Resent changes by Verdy p[edit]

@Verdy p: , I do not understand your changes to this module. What problem are you trying to correct? Usually if there is a problem people report it, the code author or maintainer fixes it, puts it in the sandbox for testing and on high value page like this, you accumulate few edits like that before releasing to minimize number of edits. Looking at your edits, they seem mostly like attempts of code beautification or adding aliases to sitelinks function which is probably only used by other modules maintained by me. In the future, if there is an urgent need to fix immediate error suddenly breaking pages, than by all means come and fix or revert to a stable version. Otherwise, if you want to help please use the talk page to discuss what you want to change or propose changes in the sandbox, but do not alter 14M pages for cosmetic changes. --Jarekt (talk) 03:18, 18 May 2020 (UTC)[reply]

What do you want to say. You also cumulate tons and tons of edits (much much more than what I do) that affect millions pages ... Do you think you can be alone to make them ? Is all this wiki yours ? Really I do not make a lot of changes like you do, I concentrate on specific fixes and while I may make some minor cosmetic code changes (with small optimizations), there is always one fix needed for that. verdy_p (talk) 07:17, 18 May 2020 (UTC)[reply]

nowiki for link labels[edit]

{{Edit request}} I would like to get this change pulled from the sandbox:

This fixes a bug with Wikidata labels that contain text recognized as wikitext markup when used in wikitext link labels, e.g.:

Notice the label is incorrectly made partially bold because the English label contains '''. The issue was reported at d:Template talk:Q#Bug when label includes wikicode and d:Module talk:Wikidata label#Escaping. Thank you, —Uzume (talk) 18:16, 20 December 2020 (UTC)[reply]

✓ Done – I added test cases for this at Module:Wikidata label/sandbox/testcases [diff], fixed the sandbox code so that it actually passes the new test cases (the first version didn’t fix |link=- mode) and also didn’t break the existing test cases (the first version broke |show_id=1 mode) [diff], then copied that to the real module after verifying that the change didn’t increase the number of test failures at Module:Wikidata label/testcases [diff]. Pinging Jarekt as the module maintainer, because I don’t understand why the module has two separate sets of test cases, or why four of the non-sandbox test cases should be failing. --Lucas Werkmeister (talk) 15:02, 6 January 2021 (UTC)[reply]
Lucas thanks for fixing this. I am slowly moving from unit-test code using Module:UnitTests to the code using Module:ScribuntoUnit. As you observed in Module:Wikidata label/testcases, I found Module:UnitTests to often show failed test, when to me the output looks identical to the expected value. I will fix Module:Wikidata label/testcases. --Jarekt (talk) 17:22, 6 January 2021 (UTC)[reply]
@Lucas Werkmeister: Yes, that seems a better solution. @Jarekt: Can I get the updated the version pushed to Wikidata so the originally reported issue can be closed? Thank you, —Uzume (talk) 00:33, 7 January 2021 (UTC)[reply]
✓ Done and Uzume thank you for noticing this issue. --Jarekt (talk) 01:45, 7 January 2021 (UTC)[reply]

Better hover text[edit]

Currently, the hover text of the label is just the Q-id which isn't data that's interesting as the hover text. Having the description as the hover text will be more useful for the user (as done in Template:Q!). ChristianKl (talk) 18:58, 27 December 2020 (UTC)[reply]

ChristianKl, I synched Template:Q with d:Template:Q version, but I do not think that will help with the hover text as neither is using item description as hover text. I know how to control hover text of images but I do not think it is possible for just blue-links at least not through templates and modules. Perhaps you have different gadgets installed on Commons and wikidata and one of them handles hover text. --Jarekt (talk) 02:03, 7 January 2021 (UTC)[reply]
@Jarekt: I fixed the link. I meant template Q! and not Q on Wikidata. There are two ways to set a link on MediaWiki. You can set it via [[page]] which doesn't allow hover text. On the other hand [url linkname] can be formatted with <span class="plainlinks" title=''> to have hover text (which is used in my new Q!). ChristianKl (talk) 12:09, 7 January 2021 (UTC)[reply]
Thank you for clarification. I will look into it.--Jarekt (talk) 19:10, 7 January 2021 (UTC)[reply]
[[page|<span title="else">page</span>]] also works (page), although the need for another element is sub-optimal in both cases, as it separates the title from the link tag it augments. —Tacsipacsi (talk) 15:56, 13 January 2021 (UTC)[reply]
✓ Done I added hover text to this module. --Jarekt (talk) 03:29, 15 January 2021 (UTC)[reply]

This change broke quite a few transclusions of {{Number cat}} (for example, Category:100 (number)), though, as far as I can tell, a simple change to the template will fix most of the broken cases. Specifically, the change broke the fallback {{Number cat}} uses to retrieve the number represented by a Wikidata ID when the item for the number is missing d:Property:P1181. In such cases, {{Number cat}} assumes that {{Label}} returns nothing but the raw label and treats the returned label as a string representation of the number. Most numbers with Commons categories do have P1181 on Wikidata, but many transclusions of {{Number cat}} were using this fallback and broke anyway because the template does not attempt to use P1181 at all when the Wikidata ID is passed to it as a positional parameter instead of a named parameter, which appears to be the case in the majority of its transclusions. As far as I can tell, there isn't any reason for the template not to use P1181 in those cases, so I submitted an edit request (at Template talk:Number cat) to change that. I also included in the edit request a fix to the fallback to overcome the added <span> tags by stripping the tags using string processing templates, but that's still not robust, which is why I also brought up the matter here. Perhaps a parameter for returning the raw label? --wqnvlz (talk | contribs) 05:08, 26 January 2021 (UTC)[reply]

Urgent bug in this template[edit]

Hi Jarekt, jdx, Verdy p & Lucas Werkmeister, You have edited this module the past year and now we have a problem.

On 15 February the annual photo contest Wiki Loves Africa launches again. In all the previous years we asked uploaders to indicate from which country the photo was uploaded. To do so, we used the templates like {{Algeria}} and various others, all based on this single module. As the upload wizard is multi lingual, we also show the countries in the language of the uploader. A year ago I checked the special upload wizard for this contest, and it worked all fine. To prepare the upload wizard for this year's addition, this year for the first time a major bug is present caused somewhere in this module. If you upload a file in the contest, at the step Describe, there is a drop-down field to indicate the country. For every country the text is now showing something like: <span title="sovereign state in Africa">Angola</span>. Yes, including the span! Please fix this before Monday! Thanks! Romaine (talk) 14:07, 11 February 2021 (UTC)[reply]

Romaine, that is because, per suggestion above the current version also shows the item description when hovering over the text. For example {{Algeria}} will show as Algeria with the text shown when you hover over the text. I track down the sequence of calls:
However "{{Angola|nolink=1}}" must be really returning <span title="sovereign state in Africa">Angola</span> instead of just "Angola". I will make sure that when "nolink=1" is used the functon will not return <span> markup.  Doing… --Jarekt (talk) 14:56, 11 February 2021 (UTC)[reply]
✓ Done "{{Angola|nolink=1}}" no longer returns <span> markup, and I verified that upload no longer show them in the drop down menu. --Jarekt (talk) 15:18, 11 February 2021 (UTC)[reply]
Thanks Jarekt! It seems to work properly again. Greetings - Romaine (talk) 15:43, 12 February 2021 (UTC)[reply]

Option to disable fallback languages with getLabel[edit]

I was surprised to see that every Wikidata module — including this one — displays missing labels in a fallback language by default. This makes them useless for finding missing labels in a specific language. Shouldn't it be possible to disable this behaviour? For example, {{Label|Q17278|vep}} → ringjoon (Q17278), but there is no label for that item in vep. In this case, it silently falls back to Estonian. Instead, it should be possible to request either an empty string or the item's Q code. —Iketsi (talk) 12:28, 20 March 2021 (UTC)[reply]

Module:Wikidata label/testcases is outdated[edit]

@Jarekt: All 8 tests currently fail and need to be updated to reflect recent changes in the module. —Iketsi (talk) 13:15, 20 March 2021 (UTC)[reply]

Fixed @Iketsi --Jarekt (talk) 18:27, 2 May 2022 (UTC)[reply]
@Jarekt: Looks like 5 of them are broken again. --Iketsi (talk) 18:49, 2 September 2023 (UTC)[reply]

Capitalisation tag[edit]

Hi @Jarekt: - how can one set capitalisation to have the first letter of each word capitalised? Currently there is only 'uc: upper case' (entire label uppercase) and 'ucfirst: upper case for the first letter' (only the first letter uppercase). Sometimes the wikidata label is lowercase, but conventional use is first letter of each word capitalised [except after hyphens], e.g. House Finch, Yellow-breasted Bunting, Great Crested Grebe, etc. Can this be done, please? The module doesn't appear to support this option at the moment. Thanks! - MPF (talk) 17:54, 26 April 2022 (UTC)[reply]

MPF, I never noticed that but you are right, for example {{label|Q63118535|capitalization=ucfirst}} gives Rip Van Winkle Awakening from his Long Sleep. I use mw:Extension:Scribunto/Lua_reference_manual#mw.language:ucfirst to implement this, and I do not think there is any function that does what you would like. Let me look into it. What should we call it? --Jarekt (talk) 04:07, 27 April 2022 (UTC)[reply]
Hi @Jarekt: - thanks! I think that one is because the title is already so capitalised at its wikidata source. The problem is that frequently, wikidata does not follow the standard capitalisation of English-language species names (mainly thanks to one or two prolific wikidata editors with hostility to standardisation), using e.g. 'grey wolf' (wolf (Q18498)), when the normal standard is to cite it as 'Grey Wolf' (e.g. IUCN). For a simple name, perhaps "tc: title case"? - MPF (talk) 07:10, 27 April 2022 (UTC)[reply]
@MPF: I don’t think the module should support it. “Title case” is not entirely standardized even in English, not to mention other languages—and this module should work with (almost) any language. For example, I see szürke farkas above (in Hungarian), which is correct only this way; Szürke Farkas would be acceptable only as an institution name or journal title, not as a species name. —Tacsipacsi (talk) 08:46, 2 May 2022 (UTC)[reply]
@Tacsipacsi and Jarekt: - I'm not suggesting it should be used everywhere for every language; but just to make the option available in specific instances, like English vernacular names of species, which are routinely capitalised. The example which prompted this was File:Sympetrum flaveolum - 2021.jpg (the English description en|1= tagged {{label|Q387616}}), where the English name should appear as Yellow-winged Darter (and not "Yellow-winged darter"). It needs the ability to add as {{label|Q387616|capitalization=tc}} so the incorrect lowercase 'd' is converted to a correct uppercase 'D'. Hope this helps! - MPF (talk) 15:27, 2 May 2022 (UTC)[reply]
@MPF: But specific instances still affect all languages. Currently {{label|Q387616|capitalization=tc}} appears as úTszéLi SzitaköTő in Hungarian, which is totally wrong (actually way worse than it could be, as Jarekt seems to have treated all non-ASCII characters as word separators, instead of only Unicode whitespace—but even if the code treated only actual whitespace as word separators, it just can’t be correct, as title case per se is incorrect in Hungarian). Either care only about English, but then don’t use Wikidata (you can just type the English names directly), or care about other languages, but then don’t use formatting that makes sense only in English. —Tacsipacsi (talk) 23:57, 4 May 2022 (UTC)[reply]
@Tacsipacsi: That seem to be some issue with mw.ustring regex patterns, as they do not seem to work as advertised. I added {{label|Q387616|capitalization=tc|lang=hu}} to my unittest and used an approach that does not use regular expressions, so that {{label|Q387616|capitalization=tc|lang=hu}} now gives "Útszéli Szitakötő". --Jarekt (talk) 00:59, 5 May 2022 (UTC)[reply]
@Jarekt: Thanks, it looks much better. However, as I wrote, it’s still incorrect in Hungarian to write species names in title case, and also for any other type of phrase, there are almost certainly languages in which title case is incorrect, so I still don’t see any case where this mode would make things better rather than worse. —Tacsipacsi (talk) 17:17, 5 May 2022 (UTC)[reply]
Tacsipacsi, This is a low level template which is used by other templates and modules. The fact that it is incorrect in Hungarian to write species names in title case, does not mean that there are no other uses for it. I always assumed that "ucfirst" capitalization would capitalize each word instead of the first word, so I might use "tc" in the future where now I am using "ucfirst" cases. Also if one wants to have different capitalization rules for different languages then one can easily write a template that uses {{LangSwitch}} and {{Label}} templates with different capitalization, however it is much harder to fix capitalization once it is returned by {{Label}} template. --Jarekt (talk) 17:38, 5 May 2022 (UTC)[reply]
@Jarekt: Of course this single example doesn’t prove that there are no uses for this parameter. I didn’t state that either; I only stated that I don’t see any valid use case for this parameter. Without a demonstrated valid use case, it just adds complexity for the code base, and it tempts only-English-speaking users to use it where it’s inappropriate. —Tacsipacsi (talk) 21:01, 5 May 2022 (UTC)[reply]

✓ Done I added option "tc" which will capitalize first letter of each word. The change is minor but it took me a while to rebuild Module:Wikidata label/testcases test page. --Jarekt (talk) 18:26, 2 May 2022 (UTC)[reply]

@Jarekt: - excellent, thanks! One small problem, it is capitalising letters after hyphens as well as after spaces (i.e., "Yellow-Winged Darter"), could you change it to just after spaces and not after hyphens, please? - MPF (talk) 16:59, 4 May 2022 (UTC)[reply]
Fixed @MPF, see {{label|Q387616|capitalization=tc}} -> "Yellow-winged Darter" --Jarekt (talk) 17:41, 4 May 2022 (UTC)[reply]
@Jarekt: Brilliant, thanks! - MPF (talk) 17:45, 4 May 2022 (UTC)[reply]

"no" as link alias[edit]

It is requested that an edit or modification be made to this protected page.
Administrators/template editors: Please apply <nowiki> or {{Tl}} to the tag after the request is fulfilled.

Lucas Werkmeister

For the purpose of compatibility with certain "W" templates, which use "no" to indicate no link, it would be appreciated if "no" could be added as a valid alternative to "-" to indicate no link. From a brief once-over it appears that the change would be at lines 183, 321. 327, and 395. Thank you. OmegaFallon (talk) 19:12, 18 March 2023 (UTC)[reply]

Add functionality for Lexemes (L) and EntitySchemas (E)?[edit]

{{Edit request}} Currently, using Template:Label with Lexemes or EntitySchemas doesn't work, simply returning the exact input and linking to an error page. Would it be possible to add this functionality? OmegaFallon (talk) 20:34, 19 March 2023 (UTC)[reply]

@OmegaFallon: For Lexemes, it’s possible to access their data, but given that they don’t have labels, I don’t think it belongs in this module; if you want something like d:Template:Lexeme, it should use a separate module IMHO. For EntitySchemas, it’s not possible to access their data from another wiki. --Lucas Werkmeister (talk) 12:15, 2 March 2024 (UTC)[reply]

Implement getSiteLink, but for a single language (instead of a csv array)[edit]

Currently, it is possible to get a list of interwiki links for a given item using getSiteLink. Would it be possible to implement a function that would allow users to get the same information for a specified language? --Iketsi (talk) 19:33, 2 September 2023 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Module_talk:Wikidata_label&oldid=857270989"