Template talk:Data

color[edit]

For time being text returned from Wikidata will be shown in Green. It will be helpful for debugging.--Jarekt (talk) 02:27, 28 April 2016 (UTC)[reply]

I removed color, since it was messing things up --Jarekt (talk) 13:37, 28 April 2016 (UTC)[reply]

simpler parameter[edit]

It could not be a problem to aliase as well item= as property= with unnamed parameter 1, distinguishing by the first character "Q" or "P" ? -- sarang♥사랑 08:48, 3 November 2019 (UTC)[reply]

BUG: Parameter lang ignored for multilingual properties, all translations are returned[edit]

@Jarekt:

When we specify "item=Qnnn|property=Pnnnn", all values are returned, even when they have (and even require!) defining them with a language code, as they are translated.

For example:

"{{Data|item=Q2004972|property=P1813}}"

which returns all translations (in arbitrary order: the list is just ordered like as they are defined in the dataset, you can't guess here which language is included in each listed item):

"nº, nr., nº, Nr., nr, nº, nr., ቁ., nº, قم, nº, নম্বর, №, အမှတ်, nº, №, nº, nº, nº, 号, 號, අංක, nº, nº, nº, broj, nr., n.º, nr, nº, nº, nº, nº, nº, αριθ., નંબર, nº, nº, מס, नंबर, nº, nº, nº, nº, nº, nº, 番号, nº, ಸಂಖ್ಯೆ, №, លេខ, №, nº, ທີ, nº, nº, nr., Nr., бр., nº, നമ്പർ, nº, nru, nº, क्रमांक, №, nº, नम्बर, nr., nr., nº, شمیره, ਨੰਬਰ, شماره, nº, nr., №, nº, број, nº, nhamba, نمبر, č., št., lambar, nº, nº, namba, №, nº, எண், č., సంఖ్య, หมายเลข, nº, №, نمبر, số, nº, נומער, nº, nº, No., no. and #"

Or:

"{{Data|item=Q2004972|property=P1813|lang={{Int:Lang}}}}"

which returns all translations:

"nº, nr., nº, Nr., nr, nº, nr., ቁ., nº, قم, nº, নম্বর, №, အမှတ်, nº, №, nº, nº, nº, 号, 號, අංක, nº, nº, nº, broj, nr., n.º, nr, nº, nº, nº, nº, nº, αριθ., નંબર, nº, nº, מס, नंबर, nº, nº, nº, nº, nº, nº, 番号, nº, ಸಂಖ್ಯೆ, №, លេខ, №, nº, ທີ, nº, nº, nr., Nr., бр., nº, നമ്പർ, nº, nru, nº, क्रमांक, №, nº, नम्बर, nr., nr., nº, شمیره, ਨੰਬਰ, شماره, nº, nr., №, nº, број, nº, nhamba, نمبر, č., št., lambar, nº, nº, namba, №, nº, எண், č., సంఖ్య, หมายเลข, nº, №, نمبر, số, nº, נומער, nº, nº, No., no. and #"

Another example:

{{Data|item=Q11974|property=P1813|lang=el|displayformat=raw}}

which returns:

⁨󠀁󠁥󠁳Las Palmas󠁿⁩, ⁨󠀁󠁥󠁮Las Palmas󠁿⁩, ⁨󠀁󠁦󠁲Las Palmas󠁿⁩, ⁨󠀁󠁡󠁳󠁴Les Palmes󠁿⁩, ⁨󠀁󠁢󠁥Лас-Пальмас󠁿⁩, ⁨󠀁󠁢󠁥󠀭󠁴󠁡󠁲󠁡󠁳󠁫Лас-Пальмас󠁿⁩, ⁨󠀁󠁢󠁧Лас Палмас󠁿⁩, ⁨󠀁󠁣󠁡Las Palmas󠁿⁩, ⁨󠀁󠁩󠁴Las Palmas󠁿⁩, ⁨󠀁󠁫󠁹Лас-Пальмас󠁿⁩, ⁨󠀁󠁬󠁡Palmae󠁿⁩, ⁨󠀁󠁬󠁡󠁤Las Palmas󠁿⁩, ⁨󠀁󠁬󠁢Las Palmas󠁿⁩, ⁨󠀁󠁬󠁴Las Palmas󠁿⁩, ⁨󠀁󠁬󠁶Laspalmasa󠁿⁩, ⁨󠀁󠁭󠁳Las Palmas󠁿⁩, ⁨󠀁󠁩󠁤Las Palmas󠁿⁩, ⁨󠀁󠁪󠁶Las Palmas󠁿⁩, ⁨󠀁󠁳󠁵Las Palmas󠁿⁩, ⁨󠀁󠁤󠁥Las Palmas󠁿⁩, ⁨󠀁󠁮󠁬Las Palmas󠁿⁩, ⁨󠀁󠁶󠁬󠁳Las Palmas󠁿⁩, ⁨󠀁󠁥󠁬Λας Πάλμας󠁿⁩, ⁨󠀁󠁥󠁭󠁬Las Pàlmas󠁿⁩, ⁨󠀁󠁣󠁥󠁢Las Palmas󠁿⁩, ⁨󠀁󠁣󠁳Las Palmas󠁿⁩, ⁨󠀁󠁡󠁲لاس بالماس󠁿⁩, ⁨󠀁󠁲󠁵Лас-Пальмас󠁿⁩, ⁨󠀁󠁫󠁯라스팔마스󠁿⁩, ⁨󠀁󠁵󠁲لاس پالماس󠁿⁩, ⁨󠀁󠁨󠁩लॉस पामास󠁿⁩, ⁨󠀁󠁳󠁩ලාස් පැල්මාස්󠁿⁩, ⁨󠀁󠁫󠁡ლას-პალმასი󠁿⁩, ⁨󠀁󠁭󠁲लास पाल्मास󠁿⁩, ⁨󠀁󠁪󠁡ラス・パルマス󠁿⁩, ⁨󠀁󠁵󠁫Лас-Пальмас󠁿⁩, ⁨󠀁󠁴󠁴Лас-Пальмас󠁿⁩, ⁨󠀁󠁨󠁹Լաս Պալմաս󠁿⁩, ⁨󠀁󠁰󠁮󠁢لاس پالماس󠁿⁩, ⁨󠀁󠁴󠁥లాస్ పాల్మాస్󠁿⁩, ⁨󠀁󠁧󠁬As Palmas󠁿⁩, ⁨󠀁󠁳󠁧󠁳Las Palmos󠁿⁩, ⁨󠀁󠁶󠁥󠁰Las Pal'mas󠁿⁩, ⁨󠀁󠁨󠁹󠁷Լաս Փալմաս󠁿⁩, ⁨󠀁󠁳󠁲󠀭󠁥󠁣Лас Палмас󠁿⁩, ⁨󠀁󠁨󠁲Las Palmas󠁿⁩, ⁨󠀁󠁳󠁲󠀭󠁥󠁬Las Palmas󠁿⁩, ⁨󠀁󠁳󠁲Las Palmas / Лас Палмас󠁿⁩, ⁨󠀁󠁳󠁨Las Palmas󠁿⁩, ⁨󠀁󠁷󠁯Las Palmasu󠁿⁩, ⁨󠀁󠁴󠁡லாசு பல்மாசு󠁿⁩ και ⁨󠀁󠁦󠁩Las Palmas󠁿⁩

and with numval=1:

{{Data|item=Q11974|property=P1813|lang=el|numval=1|displayformat=raw}}

we just get the first item of the list, not even in the requested language (this should be Greek, even if fallbacks are used):

⁨󠀁󠁥󠁳Las Palmas󠁿⁩

Ideally: This should also work inside {{Label}} by allowing it to select a value in one or more specific properties (official name, short name, local name...) in a prefered order:

if the item defines the 1st specified property (in any number of language), the list should be filtered by language fallbacks (if that property is not defined for the default language, the default for fallbacks should be the 1st listed value)
otherwise the specified next property should be queried in the item (and used the same way with fallbacks),
and if these specified properties are not found in the item, the default labels of the item will be used (also with their existing fallbacks), as it is today in {{Label}} where there's no way to specify a property ID with "properties=P1813", or an ordered list of property IDs like "properties=P1813,P1448", for short name (P1813) and official name (P1448).
The same remark applies to alternate names for taxons (the default label of a taxon is usually its scientific name, we'd like to get a vernacular name from a different property, and if none, fallback to the scientific name from the label
Some other items are defined the reversed way and their label is the vernacular name (and its aliases) while the scientific name is in a property, the difference is in how fallbacks are treated: first queries the properties then the labels, but do not apply fallbacks at all steps but merge the lists by keeping the first existing value without overwriting them with the next properties or labels; finally use the merged list with normal fallback rules: this operating mode would be indicated by a flag like "valsoverride=yes".
If "numval=1" is used, fallback rules are used in all cases; for othercases, no fallbacks are used and the query should return a list, ordered alphabetically by the formatter, which could also have a flag "removedup=yes" to remove duplicate and empty values in the "raw" format, which is just a comma-separated list (using the list format and separators for the language requested, or the specified separator if there's one).

The "lang" parameter is still completely ignored (and does not take any default) to select an appropriate value, and certainly not all possible values (which is complete non-sense!) the language is only used to format the list (with appropriate comma separators and final conjunction).

We can still set the "numval=1" to just return 1 value at most, but the choice of language is arbitrary and does not match the expected language:

"{{Data|item=Q2004972|property=P1813|numval=1|lang=en}}" gives "nº" (incorrect)
"{{Data|item=Q2004972|property=P1813|numval=1|lang=fr}}" gives "nº" (correct, but only by chance)
"{{Data|item=Q2004972|property=P1813|numval=1|lang=zh}}" gives "nº" (incorrect)
"{{Data|item=Q2004972|property=P1813|numval=1|lang=ar}}" gives "nº" (incorrect)

Note that short name (P1813) is necessarily language-specific (according to its datatype definition), and requires setting a language when inputing data. So the lang parameter MUST be taken into account (and by default, if it's not specified it should be the user language).

This is a general bug for all properties defined with a language-specific text datatype (which are then completely unusable from the wiki). There's no way for now to make the correct language selection (with fallbacks where needed).

Invoking "p.formatStatementsE" from {{Data}} should still honor the lang=parameter (when it's present): just make it optional, otherwise it whould behave exactly like "p.formatStatements" in Lua, but still this does not work when invoking it directly in the Module:Wikidata:

"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813}}" gives "nº, nr., nº, Nr., nr, nº, nr., ቁ., nº, قم, nº, নম্বর, №, အမှတ်, nº, №, nº, nº, nº, 号, 號, අංක, nº, nº, nº, broj, nr., n.º, nr, nº, nº, nº, nº, nº, αριθ., નંબર, nº, nº, מס, नंबर, nº, nº, nº, nº, nº, nº, 番号, nº, ಸಂಖ್ಯೆ, №, លេខ, №, nº, ທີ, nº, nº, nr., Nr., бр., nº, നമ്പർ, nº, nru, nº, क्रमांक, №, nº, नम्बर, nr., nr., nº, شمیره, ਨੰਬਰ, شماره, nº, nr., №, nº, број, nº, nhamba, نمبر, č., št., lambar, nº, nº, namba, №, nº, எண், č., సంఖ్య, หมายเลข, nº, №, نمبر, số, nº, נומער, nº, nº, No., no. and #"
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|lang=en}}" gives "nº, nr., nº, Nr., nr, nº, nr., ቁ., nº, قم, nº, নম্বর, №, အမှတ်, nº, №, nº, nº, nº, 号, 號, අංක, nº, nº, nº, broj, nr., n.º, nr, nº, nº, nº, nº, nº, αριθ., નંબર, nº, nº, מס, नंबर, nº, nº, nº, nº, nº, nº, 番号, nº, ಸಂಖ್ಯೆ, №, លេខ, №, nº, ທີ, nº, nº, nr., Nr., бр., nº, നമ്പർ, nº, nru, nº, क्रमांक, №, nº, नम्बर, nr., nr., nº, شمیره, ਨੰਬਰ, شماره, nº, nr., №, nº, број, nº, nhamba, نمبر, č., št., lambar, nº, nº, namba, №, nº, எண், č., సంఖ్య, หมายเลข, nº, №, نمبر, số, nº, נומער, nº, nº, No., no. and #"
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|lang=fr}}" gives "nº, nr., nº, Nr., nr, nº, nr., ቁ., nº, قم, nº, নম্বর, №, အမှတ်, nº, №, nº, nº, nº, 号, 號, අංක, nº, nº, nº, broj, nr., n.º, nr, nº, nº, nº, nº, nº, αριθ., નંબર, nº, nº, מס, नंबर, nº, nº, nº, nº, nº, nº, 番号, nº, ಸಂಖ್ಯೆ, №, លេខ, №, nº, ທີ, nº, nº, nr., Nr., бр., nº, നമ്പർ, nº, nru, nº, क्रमांक, №, nº, नम्बर, nr., nr., nº, شمیره, ਨੰਬਰ, شماره, nº, nr., №, nº, број, nº, nhamba, نمبر, č., št., lambar, nº, nº, namba, №, nº, எண், č., సంఖ్య, หมายเลข, nº, №, نمبر, số, nº, נומער, nº, nº, No., no. et #"
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|lang=zh}}" gives "nº、nr.、nº、Nr.、nr、nº、nr.、ቁ.、nº、قم、nº、নম্বর、№、အမှတ်、nº、№、nº、nº、nº、号、號、අංක、nº、nº、nº、broj、nr.、n.º、nr、nº、nº、nº、nº、nº、αριθ.、નંબર、nº、nº、מס、नंबर、nº、nº、nº、nº、nº、nº、番号、nº、ಸಂಖ್ಯೆ、№、លេខ、№、nº、ທີ、nº、nº、nr.、Nr.、бр.、nº、നമ്പർ、nº、nru、nº、क्रमांक、№、nº、नम्बर、nr.、nr.、nº、شمیره、ਨੰਬਰ、شماره、nº、nr.、№、nº、број、nº、nhamba、نمبر、č.、št.、lambar、nº、nº、namba、№、nº、எண்、č.、సంఖ్య、หมายเลข、nº、№、نمبر、số、nº、נומער、nº、nº、No.、no.和#"
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|lang=ar}}" gives "nº، nr.، nº، Nr.، nr، nº، nr.، ቁ.، nº، قم، nº، নম্বর، №، အမှတ်، nº، №، nº، nº، nº، 号، 號، අංක، nº، nº، nº، broj، nr.، n.º، nr، nº، nº، nº، nº، nº، αριθ.، નંબર، nº، nº، מס، नंबर، nº، nº، nº، nº، nº، nº، 番号، nº، ಸಂಖ್ಯೆ، №، លេខ، №، nº، ທີ، nº، nº، nr.، Nr.، бр.، nº، നമ്പർ، nº، nru، nº، क्रमांक، №، nº، नम्बर، nr.، nr.، nº، شمیره، ਨੰਬਰ، شماره، nº، nr.، №، nº، број، nº، nhamba، نمبر، č.، št.، lambar، nº، nº، namba، №، nº، எண்، č.، సంఖ్య، หมายเลข، nº، №، نمبر، số، nº، נומער، nº، nº، No.، no. و#"

Such result can never make any sense in ANY property with a language-specific text datatype !

I don't understand why this works only with instance of (P31) (whose datatype is just an "element", which has a single value but from which you'll query labels, and not a language-specific value directly set in the property value, without any indirection to other elements):

"{{#invoke:Wikidata|formatStatementsE|item=Q42|property=P31}}" gives "human"
"{{#invoke:Wikidata|formatStatementsE|item=Q42|property=P31|lang=en}}" gives "human"
"{{#invoke:Wikidata|formatStatementsE|item=Q42|property=P31|lang=fr}}" gives "être humain"
"{{#invoke:Wikidata|formatStatementsE|item=Q42|property=P31|lang=zh}}" gives "人類"
"{{#invoke:Wikidata|formatStatementsE|item=Q42|property=P31|lang=ar}}" gives "إنسان"

Note that the work around would be to create another specific element and then, either change the property datatype to "element" or defining a new property. But this is also non-sense.

So you need to fix Module:Wikidata so that it will inspect the property value datatype: if it's an element datatype, behave like today. It's it's a localizable text datatype, filter the list of values (by the lang parameter if provided, or by the user language, using fallbacks in both cases); for other datatypes (non localizable like numbers or dates) behave like today and return the list (but format number or date values according to the language).

Note that the submodule Module:Wikidata/GetClaims allows setting the parameter "isinlang=*", but this is in fact very bad, and does not perform any fallback: it just allows filtering by strict equality of the language code. This should be deprecated to use "lang=*"", with fallback list selection in all cases: the absence of language parameter should never return the whole unfiltered list for the same property on the same element, or if there's no such translation available in the specified language, it should use fallbacks from other existing translations:

"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|isinlang={{int:lang}}}}" gives "nr., No., no. and #" (OK for some user languages only)
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|isinlang=en}}" gives "nr., No., no. and #" (OK)
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|isinlang=en-GB}}" gives "" (not found and no fallback !)
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|isinlang=fr}}" gives "nº" (OK)
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|isinlang=zh}}" gives "" (not found and no fallback !)
"{{#invoke:Wikidata|formatStatementsE|item=Q2004972|property=P1813|isinlang=ar}}" gives "قم" (OK)

This means that multilingual properties whose values are a set of monolingual texts (texts values with a specified and required language code) are unusable on Commons with this Module:Wikidata.

verdy_p (talk) 17:50, 20 June 2019 (UTC)[reply]

Note: I'm starting to fix it in Module:Wikidata/GetClaims (tests are still ongoing to fix also several other less dramatic issues, including some performance problems when processing long lists of properties, notably within recursive loops; but also with a now broken test of date properties). verdy_p (talk) 11:37, 22 June 2019 (UTC)[reply]

Another bug in this list (without "numval=1"): even if we specified the displayformat "raw", the redenred list is actually not in raw format (i.e. not plain text), it uses value, which is incorrect for bidi rendering of the list; the span element should be a bdi (otherwise the list is broken if there are items anywhere in Arabic or Hebrew, even if Arabic RTL comma separators are used)! This is a bug of the list formatter...

<div lang="ar" dir="rtl" style="text-align:right">{{Data|item=Q11974|property=P1813|lang=ar}}</div>

returned a unusable (broken) list if using "span" instead of "bdi" for encapsulating each listed item:

Las Palmas، Las Palmas، Las Palmas، Les Palmes، Лас-Пальмас، Лас-Пальмас، Лас Палмас، Las Palmas، Las Palmas، Лас-Пальмас، Palmae، Las Palmas، Las Palmas، Las Palmas، Laspalmasa، Las Palmas، Las Palmas، Las Palmas، Las Palmas، Las Palmas، Las Palmas، Las Palmas، Λας Πάλμας، Las Pàlmas، Las Palmas، Las Palmas، لاس بالماس، Лас-Пальмас، 라스팔마스، لاس پالماس، लॉस पामास، ලාස් පැල්මාස්، ლას-პალმასი، लास पाल्मास، ラス・パルマス، Лас-Пальмас، Лас-Пальмас، Լաս Պալմաս، لاس پالماس، లాస్ పాల్మాస్، As Palmas، Las Palmos، Las Pal'mas، Լաս Փալմաս، Лас Палмас، Las Palmas، Las Palmas، Las Palmas / Лас Палмас، Las Palmas، Las Palmasu، லாசு பல்மாசு وLas Palmas

And:

{{Data|item=Q11974|property=P1813|lang=ar|numval=1}}

which still does not even return the requested Arabic name but just the first defined value (in arbitrary language):

Las Palmas

I just fixed the small bug using "bdi" instead of "span".

However "numval=1" still does not work as expected, and the list is still not properly ordered (and optionally deduplicated). verdy_p (talk) 16:39, 7 July 2020 (UTC)[reply]

Now with the raw format (no HTML, only Unicode plain-text): If we want a really raw format (plain text only without HTML), the "bdi" tags have can be replaced by standard Unicode Bidi "isolate" controls U+2068 (FSI) and U+2069 (PDI). There will still not be any language indicator, unless we use Unicode tags from the special plane (U+E0000..U+E007F) at start of the isolated substring encapsulated by these Bidi controls): this tags block was once temporarily deprecated in Unicode (it was initially an addition intended for HTML before languge tagging was possible), but it is now recommanded once again, in combination with emojis or within Bidi isolates or between paired punctuations, or for locale-specific rendering in fonts, or for other future uses (including texts outside HTML/XML contexts, such as plain-text emails).

⁨󠀁󠁥󠁳Las Palmas󠁿⁩، ⁨󠀁󠁥󠁮Las Palmas󠁿⁩، ⁨󠀁󠁦󠁲Las Palmas󠁿⁩، ⁨󠀁󠁡󠁳󠁴Les Palmes󠁿⁩، ⁨󠀁󠁢󠁥Лас-Пальмас󠁿⁩، ⁨󠀁󠁢󠁥󠀭󠁴󠁡󠁲󠁡󠁳󠁫Лас-Пальмас󠁿⁩، ⁨󠀁󠁢󠁧Лас Палмас󠁿⁩، ⁨󠀁󠁣󠁡Las Palmas󠁿⁩، ⁨󠀁󠁩󠁴Las Palmas󠁿⁩، ⁨󠀁󠁫󠁹Лас-Пальмас󠁿⁩، ⁨󠀁󠁬󠁡Palmae󠁿⁩، ⁨󠀁󠁬󠁡󠁤Las Palmas󠁿⁩، ⁨󠀁󠁬󠁢Las Palmas󠁿⁩، ⁨󠀁󠁬󠁴Las Palmas󠁿⁩، ⁨󠀁󠁬󠁶Laspalmasa󠁿⁩، ⁨󠀁󠁭󠁳Las Palmas󠁿⁩، ⁨󠀁󠁩󠁤Las Palmas󠁿⁩، ⁨󠀁󠁪󠁶Las Palmas󠁿⁩، ⁨󠀁󠁳󠁵Las Palmas󠁿⁩، ⁨󠀁󠁤󠁥Las Palmas󠁿⁩، ⁨󠀁󠁮󠁬Las Palmas󠁿⁩، ⁨󠀁󠁶󠁬󠁳Las Palmas󠁿⁩، ⁨󠀁󠁥󠁬Λας Πάλμας󠁿⁩، ⁨󠀁󠁥󠁭󠁬Las Pàlmas󠁿⁩، ⁨󠀁󠁣󠁥󠁢Las Palmas󠁿⁩، ⁨󠀁󠁣󠁳Las Palmas󠁿⁩، ⁨󠀁󠁡󠁲لاس بالماس󠁿⁩، ⁨󠀁󠁲󠁵Лас-Пальмас󠁿⁩، ⁨󠀁󠁫󠁯라스팔마스󠁿⁩، ⁨󠀁󠁵󠁲لاس پالماس󠁿⁩، ⁨󠀁󠁨󠁩लॉस पामास󠁿⁩، ⁨󠀁󠁳󠁩ලාස් පැල්මාස්󠁿⁩، ⁨󠀁󠁫󠁡ლას-პალმასი󠁿⁩، ⁨󠀁󠁭󠁲लास पाल्मास󠁿⁩، ⁨󠀁󠁪󠁡ラス・パルマス󠁿⁩، ⁨󠀁󠁵󠁫Лас-Пальмас󠁿⁩، ⁨󠀁󠁴󠁴Лас-Пальмас󠁿⁩، ⁨󠀁󠁨󠁹Լաս Պալմաս󠁿⁩، ⁨󠀁󠁰󠁮󠁢لاس پالماس󠁿⁩، ⁨󠀁󠁴󠁥లాస్ పాల్మాస్󠁿⁩، ⁨󠀁󠁧󠁬As Palmas󠁿⁩، ⁨󠀁󠁳󠁧󠁳Las Palmos󠁿⁩، ⁨󠀁󠁶󠁥󠁰Las Pal'mas󠁿⁩، ⁨󠀁󠁨󠁹󠁷Լաս Փալմաս󠁿⁩، ⁨󠀁󠁳󠁲󠀭󠁥󠁣Лас Палмас󠁿⁩، ⁨󠀁󠁨󠁲Las Palmas󠁿⁩، ⁨󠀁󠁳󠁲󠀭󠁥󠁬Las Palmas󠁿⁩، ⁨󠀁󠁳󠁲Las Palmas / Лас Палмас󠁿⁩، ⁨󠀁󠁳󠁨Las Palmas󠁿⁩، ⁨󠀁󠁷󠁯Las Palmasu󠁿⁩، ⁨󠀁󠁴󠁡லாசு பல்மாசு󠁿⁩ و⁨󠀁󠁦󠁩Las Palmas󠁿⁩

And:

{{Data|item=Q11974|property=P1813|lang=ar|numval=1|displayformat=raw}}

which still does not even return the requested Arabic name but just the first defined value (in arbitrary language):

⁨󠀁󠁥󠁳Las Palmas󠁿⁩

This also works like with bdi HTML tags and properly encapsulates the isolates and still preserves the language tags inside the plain-text (these Unicode controls and tags should all be "invisible" in browsers with the Unicode Bidi Algorithm version 2 standardizing isolates).

You'll note however that, because it is a single string, you may see different fonts used in browsers: each HTML elements are rendered separately and may be styles separately. When using the raw format, there's a single text element generated for the list which is styled with the same fonts selected for the container element (above, you see that it uses the fonts style set for Arabic for the whole text, independantly of its content). However the Bidi behavior is the same. This raw format is still interesting because it generates consistant fonts for the whole list, and there's no change in line-height for example depending on the line-height of each "bdi" element with the HTML solution where each "bdi" element may have its own font metrics. verdy_p (talk) 09:26, 8 July 2020 (UTC)[reply]

verdy_p, A while ago I was trying to work with Module:Wikidata code, but I gave up. It is too confusing to follow and debug and too many things are broken. I also never use this template. I noticed that you began patching it up. That it great. If I need such module I usually use Module:WikidataIB, which is much more clear and robust. If anybody is using this template, maybe a better solution would be to switch and use Module:WikidataIB instead. --Jarekt (talk) 16:54, 8 July 2020 (UTC)[reply]

I did not find any implementation in WikidataIB for formatting lists of values. Anyway I still don't see any advantage in Module:WikidataIB compared to Module:Wikidata which has still more functionalities. WikidataIB seems to be a fork (but with its own incompatiblities). One way to go would be to get a situation were both get the same results and functionalities so that we can keep one. Module:Wikidata is still the most widely used, and things that don't work can be fixed. I'm making very slow progressive edits to it. The main issue however is not in those two modules but in the Wikidata API itself and how it is exposed. The way it caches things is wrong, and as well the wikidata REST API is way too verbose (too much redundancies inherited from the past in its JSON format, this uses a lot of memory in cache, even if the cache is restricted), and this affects BOTH or our modules equally; as well the REST API still lacks support for filters and the current base module caches too much things we never use (with the exception of labels, ALL properties of anyu item are loaded, there's no way to select the properties we want to keep and there's still no language filter for monolingual texts, that should better be resolved with their fallbacks directly in the Wikidata/Wikibase server). verdy_p (talk) 17:54, 8 July 2020 (UTC)[reply]

Template talk:Data

color[edit]

simpler parameter[edit]

BUG: Parameter lang ignored for multilingual properties, all translations are returned[edit]

Navigation menu

Search