Module talk:Wd

Module:Wd is permanently protected from editing as it is a heavily used or highly visible module. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit.

This is the talk page for discussing improvements to the Wd module.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1Auto-archiving period: 3 months

	This module does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:
Wikidata This module is within the scope of WikiProject Wikidata, a collaborative effort to improve Wikipedia's integration with Wikidata. If you would like to participate, please visit the project page.WikidataWikipedia:WikiProject WikidataTemplate:WikiProject WikidataWikidata

Use Wikipedia talk:Wikidata for general Wikidata support discussions.

Text and/or other creative content from this version of Module:Wd was copied or moved into Module:European and national party data/Wd with this edit on 22 May 2025. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

We have a problem on cywiki where we have pages taking references from Wikidata. In 2023, @Janhrach very kindly forked the code and applied some additional handling to prevent visible errors. Time moves on and the code in the module has been refactored. I applied this version but it shows errors again - see https://cy.wikipedia.org/wiki/8_Mile

I would like to keep the module up-to-date, so I had various attempts to re-apply the previous fix - but as variables have changed, it's quite tricky. There are also some more significant errors regarding those properties such as Rotten Tomatoes and Meta Critic, which is potentially easier to fix. Is there a possibility of handling this in an easier way? I would prefer not to put in special handling just for us as it limits future updates, but it would be good to know what's feasible. I could revert my changes to what was working, but I suspect that I would also need to revert other updates to Citation/CS1 modules as well. Thank you. Dafyddt (talk) 22:42, 22 August 2025 (UTC)[reply]

Regarding the specific errors you have mentioned, the problem was that Wikidata says that references citing online databases need to contain both stated in (P248) and a property of the External identifier data type, while the references causing errors contained only the latter. This may seem like a minor technicality, but database references are handled by an ugly hack in the module, and I do not want to make this hacky code more complicated to support references like this. I plan to fix this issue by creating a separate template for citing database references; this will hopefully also eliminate cryptic error messages like these.

As for re-introducing the cywiki fix, the old code is probably of little use, because the code has changed quite a lot. If it is really needed, I can try to reimplement it, but I would strongly prefer if you waited until I make the fix I have mentioned in the previous paragraph.

Also, regarding the changes to this module since I made the cywiki fix, there were two of them that are especially relevant here:

• I added verbose error messages. They should mostly be comprehensible after reading the documentation. I agree though that the errors you have mentioned are hard to understand; I will fix that.
• |title= is no longer a mandatory param for {{Cite web}}. In practice, this means that missing titles in references do not cause errors in this module, but in the citation template, like you see in the article you have linked. This hopefully made the errors more understandable. When I create the database-citation template, many of these missing-title errors could be eliminated.

—Janhrach (talk) 14:19, 26 August 2025 (UTC)[reply]

|title= is no longer a mandatory param for {{Cite web}}. False. I don't know where you got that idea but you are mistook. |title= is, and likely will always be, required by {{cite web}}. If you have found some place where it is stated that |title= is not required, name that place so that it can be visited and fixed.

—Trappist the monk (talk) 14:40, 26 August 2025 (UTC)[reply]

I meant that this module does not consider it mandatory. I wrote that this means that missing titles in references do not cause errors in this module, but in the citation template[...] Janhrach (talk) 14:43, 26 August 2025 (UTC)[reply]

Yes, I saw that, but your initial declaration that |title= is not required by {{cite web}} is false. That declaration cannot be allowed to stand unchallenged.

—Trappist the monk (talk) 14:52, 26 August 2025 (UTC)[reply]

I should have made it clear that I refered to my changes to this module. I now see that changes since I made the cywiki fix could have been interpreted as including changes to CS1. Janhrach (talk) 14:59, 26 August 2025 (UTC)[reply]

Thanks for the reply! I will wait until your changes are made and may look at reverting our copy of Wd until that's done. Dafyddt (talk) 18:20, 26 August 2025 (UTC)[reply]

Hello, could we have more customization on Language label? I mean the part when code constructs cite web etc. I see it uses aliasesP.language which means for Q1860 it picks "English". Maybe we could "tell" in i18n configuration to return value of ISO 639-1 or even P424 if that language has it, of course we always fallback to aliasesP.language. This issue comes from my local wiki, for example Module is returning label in cite web that is giving CS1 error unrecognized language. Zygimantus (talk) 13:00, 28 August 2025 (UTC)[reply]

Possible? Certainly. But there other, possibly more important issues to fix first, and I do not want to devote too much time to this module. (Its creator has seemingly abandoned it.) A temporary solution would be to map aliasesP.language to an empty parameter, which would cause the aliasesP.language to be ignored. Janhrach (talk) 15:01, 5 September 2025 (UTC)[reply]

Yeah, need to think about it. I am generally using practice for modules from enwiki like this: I treat them like upstream repo and I do not want to "fork more" than adding translations or other minor localizations. Code changes in local wiki will mean that we would deviate too much from original code and could cause many problems. Zygimantus (talk) 10:19, 10 September 2025 (UTC)[reply]

Yes, but the temporary workaround I proposed would imply modifying Module:wd/i18n (which is expected to be modified on other wikis), not the main module. Also, thinking about this issue, I may look into it sooner than I originally planned, because the solution I have in mind could also fix other problem, if it works. But I am quite busy these days, so don't expect anything for at least a month. Janhrach (talk) 19:53, 17 September 2025 (UTC)[reply]

Note for myself: Maybe modify getReferenceDetails/getReferenceDetail to make using getValue optional (replacable with alternatives). This could also be used to make handling of author params more flexible. Janhrach (talk) 19:17, 18 March 2026 (UTC)[reply]

The getReference method is quite cluttered and complicated. Fixing the |language= issue reported above would exacerbate this problem. One solution would be to create separate wrapper templates/submodules, one for Cite web and one for Cite Q, that would take QIDs as params, and generate Cite web/Cite Q calls with the QIDs converted to the form required by the citation templates. I think separating this functionality into wrappers would result in less clutter in the getReference function. Namely, this functionality would be moved into the wrapper templates:

• special handling for the first, unnamed param of Cite Q, which always needs to be given as a QID
• special handling of external-id properties, which are used (in some situations) to generate |url= for Cite web (This would enable removing the all the additionalProcessedProperties-related code cruft.)
• special handling of |language= in Cite web
• the methods getReferenceDetail and getReferenceDetails
• (possibly) special handling of numbered parameters, like |author= of Cite web.

One downside is that editors who copy this module to other wikis would need to notice the new wrapper templates/submodules, and adjust their /i18n. Failure to do the latter will not result in explicit error messages, but in weird references that contain QIDs instead of the wanted params.

Another downside would be that that the option of creating references that do not contain wikilinks would need to be removed. But I can't think why would anybody need this.

But speaking of other wikis, this change would have an advantage of letting their editors tweak the wrappers without worrying about the need of porting changes to new versions of the main module.

What do you think? Pinging Zygimantus.

—Janhrach (talk) 17:31, 18 September 2025 (UTC)[reply]

I am ok whatever decision is, logical to have configurable on i18n side, maybe refactor how much possible, so Wd has only fetching logic but what to fetch and what to show should be controlled in a smart way using i18n. Zygimantus (talk) 13:49, 19 September 2025 (UTC)[reply]

• I too would like to see special handling of external-id properties but going further, if a wikimedia template is given for a reference source using an external-id, WD should use that citation template instead of {{cite web}} with the assumption that the wikimedia template is based on cite web and thus is typically setting parameters such as the identifier and URL. e.g. {{cite cgndb}} and {{cite bivouac}}. This would also fix the issues where WD is not retrieving the publisher and author. RedWolf (talk) 20:02, 25 October 2025 (UTC)[reply]

Thinking this over, I don't think this is a good idea; it's too disruptive and it makes the thing more complex than it should be. Janhrach (talk) 18:53, 18 March 2026 (UTC)[reply]

If a WD property value has multiple references and you enclose the returned template value in <ref></ref> you end up with just one reference rather than multiple. For example, the elevation property value for Mount Robson (Q1161258) has two references but it ends up showing as a single reference but with both sources given in the one reference which is not ideal and technically incorrect as they should be displayed as separate references.
i.e.

The elevation of [[Mount Robson]] is {{Wikidata|property|raw|Q1161258|P2044}} metres.<ref>{{Wikidata|references|raw|Q1161258|P2044}}</ref>

The elevation of Mount Robson is 3954 metres.^[1]

Do I have to write a module that takes the output from {{Wikidata}} and wrap each citation with separate <ref></ref> or is there a template parameter that will do this for me? RedWolf (talk) 01:11, 22 October 2025 (UTC)[reply]

Two examples:

• {{Wikidata|references|raw|Q1161258|P2044}}

  "Mount Robson". Bivouac Mountain Encyclopedia. Retrieved 20 October 2025. "Topographic map of Mount Robson". OpenTopoMap. Retrieved 20 January 2025.

• {{Wikidata|references|Q1161258|P2044}}

  ^[1][2]

I am not sure if I understand you correctly, but I think that the latter example is what you want. In that case, you shouldn't use the raw argument.

—Janhrach (talk) 15:12, 23 October 2025 (UTC)[reply]

Yea I tried w/o the "raw" but then the references didn't show up properly in the References section. That problem seems to have been caused by wrapping the template output with <ref></ref>. The documentation is not clear that it wraps each citation template it generates with <ref></ref>. Thanks for the help. RedWolf (talk) 05:40, 25 October 2025 (UTC)[reply]

I have clarified the documentation. Janhrach (talk) 17:56, 9 November 2025 (UTC)[reply]

Was just looking at this module and the possibility of using it to pull some data in from Wikidata, only to notice it doesn't handle language code fallback for English language variants (the only workaround is setting 'multilanguage' which will pull in text in any language). Just documenting my investigation/possible solution.

Specifically, we've currently got this at line 879:

       elseif datatype == 'monolingualtext' then
			if anyLang or datavalue['language'] == self.langCode then
				return datavalue['text']
			else
				return nil

This will work (on English Wikipedia) if the text is in 'en' but not if it is in 'en-gb' or 'en-ca'.

When setting up the configuration object, we could add something like:

cfg.subLangCodes = {}
if cfg.langCode == "en" then
  cfg.subLangCodes = {["en-ca"] = true, ["en-gb"] = true}
end

Then when we're retrieving text values, we could do something like this. (My Lua might be a bit rusty...)

       elseif datatype == 'monolingualtext' then
			if anyLang or datavalue['language'] == self.langCode or self.subLangCodes[datavalue['language']] then
				return datavalue['text']
			else
				return nil

That way we'd not return a nil when there's a valid Canadian or British English text, with nothing else.

Other options — There's a bunch of other things we could also do...

Kind of a silly one, but worth noting - if the page has {{Use British English}} (or even {{Use Oxford spelling}}), we could prioritise the en-gb value over the other variants, and if it has {{Use Canadian English}}, we could prioritise the en-ca text, otherwise grab 'en' if it exists, or en-gb/en-ca if it doesn't. (All the other English variants—American, Australian, New Zealand, Indian, Nigerian etc.—don't have their own ISO 639-3 code, or recognition in the mw.language API, as far as I can tell.)

More importantly, and in terms of how to make this language-agnostic (so it could be used on other wikis with language codes - perhaps pt with pt-br), the mw.language API that's exposed in Lua does let you lookup fallbacks from the specific to the more general (i.e. mw.language.getFallbacksFor("pt-br", mw.language.FALLBACK_STRICT) returns a table containing 'pt'), but it doesn't seem to have a function for identifying sub-language codes from the base language (also, outside of English and Portuguese, you've got stuff like Slovak and Czech where each one call back to each other... or the complexity of the fallback graphs around Russian and Arabic and so on as visualised here).

To abstract away the language fallback stuff, maybe it could be a module in Lua that pulls the data from fallback language data and makes it available for contexts like this.

This all seems quite complicated and given we're on English Wikipedia, and Wikidata doesn't have the ability to use a whole bunch of non-ISO languages like Jamaican Creole English etc., handling the British/Canadian English variants seems like a pragmatic solution. If other wikis are reusing the code, maybe that could be solved later? Thoughts? —Tom Morris (talk) 16:54, 18 March 2026 (UTC)[reply]

I think a language-agnostic solution would be preferrable. I have seen other Wikipedias use this module quite extensively.

Implementing a solution is not trivial when one wants to implement a fallback hierarchy. The complexity of the hierarchy doesn't matter. Imagine that an entity has two values for short name (P1813): "X" (tagged en-gb) and "Y" (tagged en-ca). You prefer Canadian English, so you prefer retrieving the name tagged en-ca. However, when you call getValue (the function you propose modifying), you call it on each of the names separately, not all of the names at once.

This means that the following situation may arise: getValue gets "X" (tagged en-gb) as an argument, but it knows you would prefer an en-ca name if it exists. However, getValue doesn't know if a en-ca name exists; it has to return "X".

The function that has information about all the names (in all languages) is State:iterate (line 2221).

—Janhrach (talk) 18:47, 18 March 2026 (UTC)[reply]