Template talk:Wikidata Infobox

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. For the archive overview, see Special:PrefixIndex/Template talk:Wikidata Infobox/Archive.

Machine-readable language for auto-hyphenated words

After introducing hyphens:auto in the infobox (or, rather, before doing so), the language of the output should be precisely marked, as hyphenation rules differ from language to language. So every single output label, description etc. should be wrapped in <span lang="LANG">...</span>, or, even better, <bdo lang="LANG" dir="DIR">...</bdo>, LANG and DIR being the language of the text chunk and the directionality (ltr or rtl) of that language, respectively. I don’t know how the module works, but it’s a must-have IMO, as without this extra markup, browsers can only guess how the word should be hyphenated, and failed guesses may produce really weird output. If the second form is used, it also helps a lot for users of right-to-left languages like Arabic or Hebrew, because in addition to their right-to-left language, there are inevitably left-to-right English labels where no translated label is available, sometimes completely mixed up. Specifying languages (either way) also helps users of assistive technologies like screen readers that can pronounce text in the right language. —Tacsipacsi (talk) 21:51, 23 April 2020 (UTC)

@RexxS: Is this something that could be incorporated in WikidataIB? Thanks. Mike Peel (talk) 18:55, 24 April 2020 (UTC)

@Mike Peel and Tacsipacsi: You want every single piece of text returned from WikidataIB for every call to be wrapped in <bdo lang="LANG" dir="DIR">...</bdo>? Wouldn't that make a mess of the way we auto-generate categories? Also, don't you think that will give the Wikidata-haters great ammunition to scrap the use of the module on enwp? Or am I going to have to start maintaining two different versions of the module?

I have a couple of alternative suggestions:

• Use a template (similar to {{Wdib}}) to add the markup to WikidataIB's output. This has the advantage that the template can have language and direction hard-coded when exported to single-language wikis.
• Write a module that calls WikidataIB, simply passing the calls and parameters to it, then wrapping the text returned in the desired markup and then returning it to the calling page.

Can you see any other solutions? --RexxS (talk) 19:54, 24 April 2020 (UTC)

@RexxS: Good points. I don't think a wrapper would work, as WikidataIB may return multiple languages for a single call (e.g., if it's returning the labels from 4 items for a property, and 2 of them are available in Arabic, but the other 2 have fallen back to English, so they need different markup). If it can't be done by default, I'd suggest adding an optional parameter... Thanks. Mike Peel (talk) 20:02, 24 April 2020 (UTC)

There's a more important point to lok at than considering the way hyphenation is performed for line wraps: look at labels shown in mixed language and notably those that may contain parts in parentheses or other punctuation or mirrorable characters: if you don't embed each translated label into a <bdi>...</bdi> element, the punctuation will go to various places or will be incorrectly mirrored and parts of the label may be separated by other unrelated items anywhere elsewhere in the list of items.

And please, don't use the deprecated <bdo>...</bdo> elements, as these old "Bidi overrides" (defined early in HTML4 at a time when the old deprecated overrides were defined in Unicode as control characters but the Bidi algorithm was still not finalized and was demonstrated to be broken and was later modified to use newer controls and a much better algorithm) will break the order of lists (the direction of the content is propagated to the content placed **after** these overrides, so the separators (like commas) or terminators (like periods ending sentences), or any additional info at end (like precisions added in parentheses, like qualifiers) may be incorrectly placed on the wrong side in the reading order of the main element containing the whole list.

Only <bdi>...</bdi> is suitable (it was added in late updates of HTML4 and is part of HTML5 since the begining, as a safer replacement for past overrides; it has the "bidi-isolation" behavior that was standardized in the second major version of the Unicode BiDi algorithm, and also added and standardized in CSS along with the preparation work for HTML5 and tests in HTML4). "bdi" mimics the behavior of "bidi-isolation" in Unicode, which has also defined equivalent Bidi controls (to be used in plain text also instead of the deprecated "override" Bidi controls). Using "bdo" element in HTML is only suitable if you have perfect and complete knowledge of what is included inside them (its initial and final directions) *and* just before *and* just after them, so "bdo" is only for old static content where you can freely add other overrides where needed; this necessary condition is not satisfied with translatable labels that can have arbitrary values (and are not necessarily in the default script that you expect most of the time for a translated language). The "bidi-isolation" mode is also different from "bidi-embedding" mode. As well "right-to-left marks" (RLM) and "left-to-right marks" (LRM) should be avoided as they are also "overrides" (they may only be used inside the static plain-text value of the translated labels themselves, where they will be added appropriately for the language and script these translated labels are targeting, when it is not suitable to insert HTML code in these plain-text labels).

With "bdi" you don't even need to specify a dir="rtl/ltr" attribute for the content (only the lang="" attribute may be relevant to indicate from which language the translated label comes from): the embedded label should already be correctly ordered as is in isolation, in its default reading order, that will be used unchanged without affecting the direction of contents placed before or after the "bdi" (the "bdi" element itself has NO direction, it is "transparent/neutral" and does not break the direction of the outer content, it perfectly isolates its inner content that will be never be splitted in several parts like with all other bidi modes). verdy_p (talk) 01:02, 25 April 2020 (UTC)

@RexxS: I don’t know how categorization by this template works. Of course it should be taken care of, but most user-visible texts of this template may potentially include wiki links, which is not suitable for categorization in the first place, so I don’t think the two purposes use the same endpoints as of now. This change makes no sense on the English Wikipedia, but that’s the only such language. It makes sense not only on Commons, but also on any monolingual wiki where that single language is different from English—when it comes to Wikidata, Arabic Wikipedia faces the same issues as Commons with Arabic interface language. This can be turned off automatically if the user language (content language in case of monolingual wikis) is English if you wish so, but should be on on non-English monolingual wikis as well.

@Verdy p: Where has <bdo> been deprecated? Mozilla Developer Network lists <bdo> as a valid, non-deprecated element, with perfect browser support. In contrast, <bdi> is also a valid, non-deprecated element, but has much poorer support: no IE, no legacy Edge (EdgeHTML), no Safari, no iOS support (on iOS every browser should use Safari’s engine, which doesn’t support it). So I don’t think time has come to use <bdi>. —Tacsipacsi (talk) 02:06, 26 April 2020 (UTC)

Deprecation of overrides is from Unicode itself that admitted that Bidi-overrides had bad effects and created Bidi-isolation especially for this purpose.

But as overrides still have some valid use (only for **static** content where you know exactly which texts is inside, and immediately before it and immediately after it) so that the effective direction is known) and there were lot of preexisting documents using overrides, this possibility has been maintained in the Bidi algorithm.

But Unicode, CSS, and HTML specs strongly recommand using isolates rather than overrides, espacially when the contents is generated and you don't know what text may be before, inside or after the embedded text. The really bad effects of overrides (including LRM and RLM controls) are wellknown and documented since long and could not be solved without the introduction of "Bisi-isolation", which was finally standardized in the second major version of the Bidi algorithm (this is the only version that everyone uses today, the former version is effectively deprecated, exactly because of multiple serious problems for punctuations, mirroring, and the absence of support isolates). "bdo" has been kept in HTML only for compatibility with former contents where its bad "propagating" effect is what was really intended by the initial content creators (and it's no easy to fix it: replacing overrides by isolates would revert these effects inside contents which "seemed" correct, and then will change the layout and the interpretation of the content).

If you are still not aware of the many problems that Bidi-overrides cause in multipart-generated contents, please document yourself. All these problems are cleanly solved by isolates which is the ONLY safe thing to do in Wikimedia for all generated contents (including notably templated lists).

verdy_p (talk) 02:30, 26 April 2020 (UTC)

Also you're wrong: isolates (and the second major version of UBA, the Unicode Bidi Algorithm which standardized isolates) is fully supported in Safari, iOS... I don't know any OS or browser that does not support isolates (and "bdi" in HTML4 or HTML5), except very old softwares created many years ago before the publication of the UBA and that were not updated at all since then (old versions of IE? their support is now ended since long).

The UBA version that added isolates was in Unicode 6.3, published on 30 September 2013, but isolates were already described in an annex before and have been requested, discussed since even longer. I can't beleive that Apple would refuse to integrate isolates in Safari or keep Safari to an antique Unicode version. The UBA is one of the most important part of the Unicode standard that cannot be ignored (even if implementing other parts may be delayed), especially by an international corporation like Apple that cannot ignore the large Arabic and Hebrew speaking markets.

In reality the only bidi mode that Apple does not support in Safari and iOS, is the "isolate-override" mode (coming from preliminary works in CSS and in Unicode before the finalization of UBA v2) which is useless, and which is different from the "isolate" and the "override" modes, by being a strange mixup initially requested but that prove to be completely ill-defined (I can't understand why Mozilla kept this experimental mode). "isolate-override" is also different from the "embed" mode (which is also part of the older Unicode standard and used by RLE/LRE control characters). The "embed" mode however works with a required explicit "direction" that propagates inside the embdded element, but unfortunately also after it, so it was also a failure but it has been kept for compatibility (Apple chose to not support that ill-defined mode too).

"bdo" (which requires and explicit rtl or ltr direction) in HTML maps to the old "override" mode (also used by RLM and RLM control characters), and the "bdi" element in HTML maps to the "isolate" mode (unlike "bdo", the "bdi" element does not require any explicit direction as its default direction is "auto").

Apple's Safari for iOS (since Safari 6, published on 30 July 2012) has full support of the "isolate" mode of CSS (from where it originated) and of the UBAv2 (that adopted the CSS definition, and that was then integrated into Unicode 6.3 standard in 2013). Are we really "too early", or is it just Apple late to change Safari to recognize the "bdi" HTML tag, when it already supports UBA2 in CSS? We can do one thing on iOS: just add a CSS stylesheet definition for iOS, stating that missing rule that Apple forgot: bdi { unicode-bidi: -webkit-isolate; } (you could add a first style with the "embed" value for old versions of iOS using Safari before v6 still not having UBAv2, but I bet almost all these old iPhones with iOS 3.1-5.1 or before sold before 2012 are dead today! Some MDN measurements indicated already they represented less than... 0.01% of the market in 2018, only for version 5.1, and all other versions before 5.1 were already undetectable). Reports indicate however that the "-webkit-" prefix is still needed (only in iOS with Chrome or Safari) for the "isolate" value in CSS, but it works !

In addition, since iOS 10 (and macOS 10.12), the API "String localizedStringWithFormat()" automatically inserts Unicode isolate controls <FSI>...<PDI> (i.e. U+2068...U+2069) around all placeholders (like the "%@" in "%@ has the highest score!" in translatable and formatable messages, that will be replaced by the arbitrary name of a user, which may be written in Arabic, but as well this message is translatable in Arabic and will allow user names in Latin; for such case, using Bidi overrides would never work at all as the inner direction of the placeholder is compeltely independant of the outer direction). The "%@" placeholder in localizable format strings, is in fact equivalent to "\u2068%s\u2069" in classic format strings (and this already worked with the text renderer in the iOS and MacOS API since mid-2012 and even earlier before with a specific API of the text renderer to support this "isolate" mode in CSS)...

See this presentation in video: "https://developer.apple.com/videos/play/wwdc2016/232/".

This is a higher level way to format strings with mixed language direction, without manually inserting directional marks (and another proof that UBAv2 of Unicode 6.3 was already integrated but here this is enforced in a more practical way so that most applications using translation templates will benefit from it, without having to encode these controls in translation units). Even though this is an improvement in the UI layout support API for iOS/MacOS, the UBA support for isolates was already present since several years in the text rendering engine itself. It was already integrated in CSS with Safari for iOS and MacOS; only the HTML renderer forgot initially to predefine the appropriate CSS style for the "bdi" element (which is still parsed correctly by Safari in the HTML DOM)...

verdy_p (talk) 02:42, 26 April 2020 (UTC)

Thanks for the detailed explanation, then let’s use <bdi lang="LANG">...</bdi>. (Actually I just noticed that the mentioned override—in a more complete form—is already present in MediaWiki:Common.css, although it isn’t loaded in mobile view, so maybe it needs to be moved into a mobile-ready gadget.) But do use it, as without that we end up with really annoying results sometimes, even with the recent widening of the box. —Tacsipacsi (talk) 23:08, 1 July 2020 (UTC)

@Tacsipacsi and Verdy p: I'm closing this as not done, since I still think it needs to be implemented in WikidataIB, not the infobox (since the infobox doesn't necessary know the language of the wording, and @RexxS: isn't around to help with that any more. Thanks. Mike Peel (talk) 17:50, 31 October 2022 (UTC)

@Mike Peel: I don’t care in which module is this resolved, I care only it gets resolved. Since this is the template that’s broken, this is a perfectly valid place to track it. And if no one will set the language machine-readably, then the auto-hyphenation should be removed. —Tacsipacsi (talk) 22:31, 1 November 2022 (UTC)

@Tacsipacsi: OK. One thing that's puzzling me is that this should probably be handled natively by MediaWiki when it's rendering a page in a given language, is that not currently happening? There are edge cases where the infobox is displaying in a mix of languages - but then there's the work-around to just add more language labels to Wikidata where there is a problem. Thanks. Mike Peel (talk) 21:58, 7 November 2022 (UTC)

@Mike Peel: The MediaWiki core parser has no knowledge about the language of the text. (Except for the page language, but that doesn’t depend on the UI language and is hardly if ever anything else than English in the category and gallery namespaces.) It sees a bunch of characters, of which it can interpret the wikitext syntax, but it cannot determine whether the string van means a type of automobile in English, a name prefix in Dutch, or the translation of “be” in Hungarian. This is why we need to tell it (or, rather, the browsers) by using appropriate markup. And by marking up the individual bits that have a language, there’s no issue with cases where some labels are in the UI language and others in some fallback language – and these are not the edge cases; even in English, there are many labels missing, not to mention “smaller” languages like French or Russian.

Wikibase, in turn, does know the language of the text in many cases (except for strings stored with data types that don’t allow setting the language), but it doesn’t include HTML markup in the returned value – and this is good this way, as the users may want to do fancy things with the result (e.g. using it in a tooltip), where HTML markup may cause issues. —Tacsipacsi (talk) 22:01, 10 November 2022 (UTC)

Wikidata property proposal "information sign"

On Wikidata I proposed a new property that could be included as media file into the Wikidata Infobox. So far only one other user has made a comment on the proposal. I think that many Commons users – especially, but not only, architectural and heritage monument photographers – could be interested in such a new property so I hope for some more responses.--Image-Improver Bonn (talk) 13:11, 21 October 2022 (UTC)

Add a test

{{Edit request}} Module:Wikidata Infobox produces an error on Category:Fièvre (1921 film) : Lua error in Module:Wikidata_Infobox at line 160: attempt to index field 'datavalue' (a nil value).

Could someone with editing rights add a test on the existence of qual.datavalue on that line? Thank you.

I made the change in the sandbox and checked it works. Seudo (talk) 08:06, 12 November 2022 (UTC)

@Seudo: There were some "no value" statements on Wikidata for some reason, now removed, and the infobox works as it is. Although your changes are probably a good idea for making sure the infobox continues to work in such cases, perhaps with a tracking category. Thanks. Mike Peel (talk) 08:44, 12 November 2022 (UTC)

Thanks, but I think it should at least display a more user-friendly message (such as "there is a problem with the X statement at Wikidata"). It's always a good idea to check that a Wikidata/Lua object exists before using it. Seudo (talk) 10:12, 12 November 2022 (UTC)

Template:Wikidata Infobox issues

hi Mike, my name is Reinhardt WIEWE. 2006 i was involved in the internationalization of the MediaWiki interface ^{Betawiki Nike} and used the nickname Gangleri. my task was faultfinding related to BiDirectional environments.
during the last year I added nearly ten thusend of links beween wikidata and [LibraryThing]. actual P7400 counter is 14,042 i focused on identities of authors and recently dikscovered the utility of Wikidata Infobox.

https://www.librarything.com/author/societiesinternation

https://www.librarything.com/author/nationsunited

https://www.librarything.com/author/smersh

https://www.librarything.com/author/akademiodeesperanto

all these items about organisations contain Authority Control links. https://www.librarything.com/author/meerbaumeisingerselm is a link about a person. it contains a link labeled "persondata.toolforge.org gnd 118579894" to [1]. i will ask that the tool should contain also Commons category (P373).

---

please help:

1. can you please include the LibraryThing author ID (P7400) value in the infobox?
   1. for persons where GND ID (P227) is present please include a link of the form https://persondata.toolforge.org/p/gnd/GND ID value labeled "persondata.toolforge gnd"
   2. for non-persons (as organisations, groups etc. ) normaly thereis a wikidata item involved please include a link of the form persondata.toolforge.org/p/wikidata/wikidata itam value
2. can you please display "YouTube video ID (P1651)" it will help to add emotions to the side

---

some years ago i was involved with Magnus authority control tool; see [2]. the number of Authority Control parties and the number of wikidata identifiers has exploded. do you have some ideas how to use a custom configuration file to select specific identifiers? some pleople would like language related links, some chess players chess rlated values, some would like music, entertainment related utems atc.

---

https://www.wikidata.org/?curid=65288749# contains some primitive querries.
[3] and [4] and LT group shmiletant

greetings from munich, germany

no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs} 15:08, 16 November 2022 (UTC)

@קיין ומוויסנדיק פּרעפֿערענצן: Please could you post these at Template talk:Wikidata Infobox, which is where we keep track of requests like this. Thanks. Mike Peel (talk) 15:10, 16 November 2022 (UTC)

(Now moved here from User talk:Mike Peel [5] Mike Peel (talk) 07:26, 17 November 2022 (UTC))

adding some show cases:

https://www.librarything.com/author/aristotle

with an imprssive https://viaf.org/viaf/7524651/#Aristotle and

https://commons.wikimedia.org/wiki/Category:Aristotle

https://www.librarything.com/author/singerisaacbashevis

with https://commons.wikimedia.org/?curid=9515157

with links to many w:en:Yiddish sites

comments:

1. there should be an anchor to acces the "Authority control" directly
2. to be continued

regards 13:10, 19 November 2022 (UTC) no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs}

rendering failures due to selfreferening of common categories

hi! https://commons.wikimedia.org/?curid=63916047 is fixed now. in the infobox the link to the wikidata item is now correct and not to the wikidata item of the commons category itself.
the fix was made by deletion of the value of the category from "in other multilingual projects". then this value could be added to the proper wikidata item about Sfânta Sava college.
in theory such errors can happen everywhere. can anybody check for similar misconfigurations? thanks in advance. gangleri aka lery raynhart aka 17:13, 24 November 2022 (UTC) no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs} no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs} 17:13, 24 November 2022 (UTC)

@קיין ומוויסנדיק פּרעפֿערענצן: The commons category link was correct, the problem was that Saint Sava College (Q3067523) and Category:Saint Sava National College alumni (Q8698590) weren't linked together using category combines topics (P971) and category's main topic (P301) - I've now done that. @LennardHofmann: do you think it would be feasible to add a tracking category for cases of instance of (P31)=Wikimedia category (Q4167836) that don't have category's main topic (P301) - and also, don't have category combines topics (P971), since those mostly wouldn't have corresponding topic items? Thanks. Mike Peel (talk) 07:41, 25 November 2022 (UTC)

Instruction for adding a sitelink on Wikidata needs update

It says "The category page needs to be linked to through a sitelink on Wikidata (under 'other sites', add the correct sitelink to 'commons')."

However, in wikidata, the section is named "Multilingual sites" not "other sites". Onthewings (talk) 18:49, 5 December 2022 (UTC)

You can change this, if you wish, at Template:Wikidata Infobox/doc — Martin (MSGJ · talk) 18:59, 14 December 2022 (UTC)

Taxon pages with wikidata, but without Taxonavigation

Hello together,

I'm working on taxon categories at the moment and I noticed that there are a lot of taxon categories with a Wikidata item associated (and Wikidata infobox), but with a missing Taxonavigation bar. If the wikidata is there, it would in most cases be easy to also add the Taxonavigation bar. So it might be helpful to add a category like "Taxon pages with wikidata, but without Taxonavigation" in those cases, so that a Taxonavigation bar could be added. I know it's a bit redundant, but the Taxonavigation adds a bit of functionality, that the Wikidata infobox doesn't. Like adding categories in the style of "Genera of Family".

What could make this a bit more difficult is that there are a couple of templates like Template:Lepidoptera that are derived from Template:Taxonavigation. Also here are two examples:

• One category with the bar Category:Agriocnemis gratiosa
• One without: Category:Agriocnemis pinheyi

Same could be done for templates like Template:VN of course.

Best, FlocciNivis (talk) 12:34, 19 December 2022 (UTC)

@FlocciNivis: The information that {{Taxonavigation}} and {{VN}} include should already be shown in the infobox, so adding them as well is redundant - and makes it more difficult to use categories since those templates take up space at the top of the category that you have to scroll past. If there are things that aren't included, then we could look at adding them into the infobox. Thanks. Mike Peel (talk) 06:01, 20 December 2022 (UTC)

Hello @Mike Peel, thank you for your answer. What the Wikidata infobox at the moment not inlcudes are certain categories that are added by the Template:Taxonavigation.

If one category is for example for a species the template will add a Category in the style of Species of Family to it, if this Category exists. The same goes for Genera as well. And I think, although I'm not sure, they will be added for all the higher-ranking taxons that have a Category in this style.

Best, FlocciNivis (talk) 21:45, 20 December 2022 (UTC)

Wikimedia Maps

@Mike Peel: I noticed the infobox at the page Category:Road II/160 (Czech Republic) displays a line of the road in the map, even though the related Wikidata item contains no link to Wikimedia Maps. How it works? Directly through Wikidata:Property:P402?

I suspect, that the infobox displays the linear or area location in the map only if the the location is defined also by any unique point coordinates using Wikidata:Property:P625. IMHO if the spacial data from Wikimedia Maps are available, their display should be not conditioned by Wikidata:Property:P625. ŠJů (talk) 23:54, 20 December 2022 (UTC)

The infobox builds a mapframe (similar to these examples) with the QID of the topic item, which is everything Kartographer needs to retrieve the geodata using the Wikimedia Maps API. Your suspicion that all this only happens if the topic item has a coordinate location (P625) statement is correct since otherwise Module:Wikidata Infobox never calls getCoordinates(). This is done to avoid displaying an empty map if Wikimedia Maps has no data about the topic item, and to avoid useless API calls. You could use the presence of a OpenStreetMap relation ID (P402) statement as a heuristic for the success of the API call, but this would probably complicate the code quite a bit. LennardHofmann (talk) 08:39, 21 December 2022 (UTC)

Automatic categorization by cause of death

{{Edit request}} It would be nice if we not only could show the Wikidata:Property:P509 (cause of death) but also put the page into a matching category, like Category:Deaths_from_pneumonia or Category:Deaths from cholera. Rettinghaus (talk) 11:00, 28 December 2022 (UTC)

Please don't use {{Edit request}} unless you have a specific change which can be copied into the template or module code. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 30 December 2022 (UTC)

I have implemented this in the sandbox module. LennardHofmann (talk) 17:57, 1 January 2023 (UTC)

Please link "Author"

Please see Category:Die Vogelwarte Rossitten der Deutschen Ornithologischen Gesellschaft und das Kennzeichnen der Vögel (1910). I expect "Johannes Thienemann" as the author being linked to Category:Johannes Thienemann (at d:Q67915 Commons sitelink and P373 are ok afaik). thx AmsaTalla (talk) 18:25, 29 December 2022 (UTC)

Thanks for reporting. Authors not being linked was actually an issue on all category pages. This is now fixed in {{Wikidata Infobox/sandbox}}. —LennardHofmann (talk) 13:18, 31 December 2022 (UTC)

Atlas ID to be changed to Louvre Collections ID

Hello

In the external IDs for Art, the ID used for the Louvre Collections items is the Wikidata property https://www.wikidata.org/wiki/Property:P1212 for Atlas database. The base is no longer published since 2021. The links may make redirections to the new Louvre Collection database but many Atlas IDs are dead links. Example: http://cartelfr.louvre.fr/cartelfr/visite?srv=car_not_frame&idNotice=20688&langue=fr in Category:Chasse_d%27Alexandre_(Louvre,_Ma_858).

Furthermore the new Louvre collections database has its own ID on Wikidata https://www.wikidata.org/wiki/Property:P9394 and more Louvre items are linked in Wikidata with this ID. Example: Q20667952 https://collections.louvre.fr/ark:/53355/cl010279155

So the use of Wikidata Atlas ID/P1212 should be changed to Louvre Collections ID/P9394.

Best regards Shonagon (talk) 18:06, 14 January 2023 (UTC)

Volume as quantity and vertical depth

I have an item Preston Resevoir - WS172 (Q116214651) which is a water resevoir, basically a cylinder. Helpfully, Sydney Water has given the volume and vertical height of the water source, which I have entered but it's not showing Volume as quantity and vertical depth. Does anyonw know why this is? Chris.sherlock2 (talk) 10:02, 16 January 2023 (UTC)

Small fix to module: unbalanced tags

I have fixed unbalanced tags in the module sandbox. Please include this change in the live module when it is next updated. Jonesey95 (talk) 17:13, 19 January 2023 (UTC)