Module talk:Wd
Module:Wd is permanently protected from editing because 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. |
|
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: | ||||||||
|
Use Wikipedia talk:Wikidata for general Wikidata support discussions. |
Related pages |
---|
Another update
editI once again altered the internal workings of the citation-rendering function in the sandbox, but also /i18n. Apart from a bugfix, in this update I tried to make much template- and param-specific behavior (previously hardcoded into the function) configurable in /i18n. Changes to /i18n are not backward-compatible. Some testcases are here. Janhrach (talk) 18:40, 15 August 2024 (UTC)
- Thanks for the info — Martin (MSGJ · talk) 18:46, 15 August 2024 (UTC)
- Done. Janhrach (talk) 09:45, 26 August 2024 (UTC)
Reference error message improvement
editFinally, I improved the reference error messages. The code is in the sandbox. /i18n
has also been modified. You can see the difference of the outputs here. I appreciate your feedback. Janhrach (talk) 17:17, 27 August 2024 (UTC)
Discussion at Template talk:Wikidata entity link § Not picking up mul labels from Wikidata entities
editYou are invited to join the discussion at Template talk:Wikidata entity link § Not picking up mul labels from Wikidata entities. Peaceray (talk) 01:10, 30 August 2024 (UTC)
- @Thayts, Janhrach, et al.: What do you think? I was thinking to change Module:Wd#L-704 from
label = mw.wikibase.getLabelByLang(id, self.langCode)
tolabel = mw.wikibase.getLabelByLang(id, self.langCode) or mw.wikibase.getLabel(id)
(at least as an interim step). Is this the right thing to do or should we just removegetLabelByLang()
all together? Currently it is also being (mis)used at Module:Wd#L-1294 (with a hardcoded "en" for the language). Incidentally this module currently also usesgetDescription()
(and notgetDescriptionByLang()
) at Module:Wd#L-2523. It seems like the language usage (and their fallbacks) is not very unified here. Thank you, —Uzume (talk) 15:11, 30 August 2024 (UTC)- I am not familiar with the Wikibase API. As for the status quo, it is not good and I already have had to fix a bug arising from a lack of label fallback. I don't know whether
getLabel
provides a good fallback mechanism, and I don't now have time to check the documentation. (Though maybe tomorrow I will have.) - As for the
hardcoded "en"
, it is required that the language is hardcoded, because the fetched label is used in a Geohack call. (However, I find it much preferable for this string to be fetched from a WD property and not from the label, because in the future, there will be no guarantee that the label will be accepted as a Geohack param.) Janhrach (talk) 19:26, 1 September 2024 (UTC)- Update: I found the documentation is linked in the linked discussion, so I didn't have to search for it. It seems that it is desirable use getLabel only. There may arise some issues, but they would (in my speculation) only affect multilingual wikis. I will look into this possible bug later. Janhrach (talk) 19:36, 1 September 2024 (UTC)
- The hypothetical bug I have mentioned quite probably won't arise, so ignore this part of the comment. Janhrach (talk) 17:53, 2 September 2024 (UTC)
- Update: I found the documentation is linked in the linked discussion, so I didn't have to search for it. It seems that it is desirable use getLabel only. There may arise some issues, but they would (in my speculation) only affect multilingual wikis. I will look into this possible bug later. Janhrach (talk) 19:36, 1 September 2024 (UTC)
- I am not familiar with the Wikibase API. As for the status quo, it is not good and I already have had to fix a bug arising from a lack of label fallback. I don't know whether
Proposed fix
editI made a fix to the sandbox. Sample output:
- English label:
- live module: Europe
- sandbox: Europe
- Multilingual label:
- live module: Douglas Adams
- sandbox: Douglas Adams
Property mapping and ignoring unrecognized parameters
editI was brought here by the following citation errors which had too much information:
Extended content
|
---|
References
|
This is partially just an edit request to add some properties to the property mapping. author (P50) and place of publication (P291) are common citation parameters that need to be added to the property mappings documented at Template:Cite Q § Bibliographic parameters and Template:Wikidata § References. I would further map genre (P136) to |type=
and published in (P1433) to |work=
.
However, I also think that this template/module refusing to produce any citation when there are unrecognized parameters is not ideal. I suggest that it should ignore unrecognized parameters without error messages in published articles, and only show a green warning message on previews.
Pinging Sdkb from their prior interest at Module talk:Wd/Archive 1 § References mapping.
Daask (talk) 08:03, 24 September 2024 (UTC)
- As for the errors containing
too much information
, there were repeated complaints that the previous error message, which only indicated that an error had occured and linked to the documentation, was unclear. And I think too little information is a lesser problem than too much information, especially when there is no middle ground. - As for the requested mappings, the usage of the mentioned properties in WD refs is not standard per wikidata:Help:Sources.
- Ignoring unknown properties is problematic, because some properties may be deliberately left from the Cite web mapping to force the module to use Cite Q. This will be very important if new output templates are added, which is something I want to do eventually. Janhrach (talk) 15:06, 27 September 2024 (UTC)
- @Janhrach: I apologize for my unclear comment. My concern was not that the error message was verbose, but rather that the error was caused by Wikidata having too much information about the citation. Daask (talk) 15:36, 27 September 2024 (UTC)
- I have made some edits to the refs on Wikidata, and I will also modify the module later. Janhrach (talk) 18:01, 27 September 2024 (UTC)
- I have added support for place of publication (P291) into the Cite web mapping. Janhrach (talk) 13:20, 5 October 2024 (UTC)
- Why? When citing a web source, that source exists somewhere (or multiple somewheres) on the intarwebs but is not tied to a physical location. Just because a box can be filled, it does not mean that it should be filled.
- —Trappist the monk (talk) 13:44, 5 October 2024 (UTC)
- I added the property because the reference number two above displayed an error, as it contained the P291, which was not in the mapping. Is the usage of "Bloomington" in
publication-place
in the above reference incorrect? Should all instances of usage like this be removed from Wikidata? Janhrach (talk) 13:58, 5 October 2024 (UTC)- Yes, incorrect. And because you are citing a website, the proper parameter is
|website=
not|publisher=
. Wikidata should contain correct data. The problem there is that there are few if any standards so editors will fill-in the boxes because 'omg!-there-is-an-empty-box!-I-must-fill-it!' All that you can do is recognize that and choose{{cite web}}
parameters appropriately. - —Trappist the monk (talk) 14:12, 5 October 2024 (UTC)
- OK, I fixed the incorrect publication-place properties on WD and reverted my edits to this module. Janhrach (talk) 14:24, 5 October 2024 (UTC)
- May I ask why you think Kinsley Institute should be in
website
, not inpublisher
? Janhrach (talk) 16:48, 5 October 2024 (UTC)- Because we cite the work (
|website=Kinsey Institute
in this case – note spelling) not the publisher (Indiana University). - —Trappist the monk (talk) 18:38, 5 October 2024 (UTC)
- Is the Kinsey Institute a work? It quite seems to match the definition of "publisher" from the Cite web documentation (
The publisher is the company, organization or other legal entity that publishes the work being cited.
). - We could say that we cite the institute's website, which has the same name as the institute. Is this what you mean?
- (Thanks for the spelling correction; I sometimes misread words and misspell them afterwards.)
- – Janhrach (talk) 12:55, 11 October 2024 (UTC)
- Is the Kinsey Institute a work? It quite seems to match the definition of "publisher" from the Cite web documentation (
- Because we cite the work (
- Yes, incorrect. And because you are citing a website, the proper parameter is
- I added the property because the reference number two above displayed an error, as it contained the P291, which was not in the mapping. Is the usage of "Bloomington" in
- I have added support for place of publication (P291) into the Cite web mapping. Janhrach (talk) 13:20, 5 October 2024 (UTC)
- I have made some edits to the refs on Wikidata, and I will also modify the module later. Janhrach (talk) 18:01, 27 September 2024 (UTC)
- @Janhrach: I apologize for my unclear comment. My concern was not that the error message was verbose, but rather that the error was caused by Wikidata having too much information about the citation. Daask (talk) 15:36, 27 September 2024 (UTC)
Summing values across items
editHi,
I am already using this module to call values for specific items (in my case, political parties, such as their number of members).
Is there a way to sum these values for several items that are all instances of an item. For instance, the parties I deal with are all instances of "European political parties", and I am trying to sum their values to display the result (e.g., the sum total number of members of all European political parties).
Is these feasible one way or another?
Thanks! Julius Schwarz (talk) 07:47, 21 October 2024 (UTC)
- This is not possible with this module. Janhrach (talk) 15:41, 25 October 2024 (UTC)
- Thanks for the reply! And too bad. Julius Schwarz (talk) 07:48, 28 October 2024 (UTC)