Help talk:Default values for labels and aliases

Beta Test

Tracked in Phabricator
Task T285156

Welcome to the Beta test for the new default values feature! Based on a long-standing community request around language fallback and based on your feedback from our previous announcement, we are currently testing the beta version on test.wikidata.org with the release planned for Q1.

Tips for an authentic experience during your tests:

• Copy over your Babel boxes from Wikidata and set your UI language.
• Try out the test Items and Properties below.

New Functionality

The beta version has the following functionality:

• You can now add default values for labels and aliases to Items and Properties. This helps to reduce repetition of the same labels and aliases over and over, which is hard to maintain and hard on our infrastructure (especially the Wikidata Query Service).
• These default values are considered in the language fallback chain whenever there are no diverging values specified for a language.
• The already available default values and language fallbacks are now clearly visible in the placeholders of the editing user interface.
• For logged-in users, there is a hint that describes the functionality and links to the help page for more details. It is available in the edit view (if you click it away, it will never come back).

Known Limitations of the testing environment

The limitations of the beta version are:

• For now, the prototype is only available on test.wikidata.org.
• You have to manually refresh the page to see the results of edits (we are fixing this in the release version, see T356201 and T135871).
• Most of the features are not available on the mobile UI (this will also not be a part of the initial release).
• The guidelines on Help:Default values for labels and aliases are still incomplete (the onboarding element will link there). See below to help craft the page!

Test Items

We created some Items on test.wikidata.org that help to evaluate the new features. Please keep them in good shape during the Beta tests:

Type	Test Case	Test Item
Names	N1 Person (Latin script)	Q42
	N2 Person (Korean script)	Q232150
	N3 Astronomical object	Q233656
	N4 Taxon (without popular name)	Q233657
	N5 Taxon (with popular name)	Q232151
Titles	T1 Scholarly article	Q233655
Symbols and characters	S1 Unicode character	Q233658
Codes	C1 Country code (as alias)	Q233659
Properties	P1 External Identifier	P590
Wikimedia Internal	W1 Disambiguation page	Q233660

Open Questions

These are the questions based on the usability testing findings that the Wikidata Development team is still exploring. Suggestions from the community will be really appreciated.

• What would be a clear name to refer to multiple languages in the termbox table? Based on the test results, the current name “default values (mul)” might be confusing. For some of our participants, it was not clear what the “(mul)” part meant. Some participants indicated that “default values” is not a language”, and found it confusing that it was included in the “Language” column. Based on that, for example, it was perceived that it is not possible to edit the default values. One suggestion from a participant was to change the text to "Default value for all languages”.
• The placeholders now visualize how the language fallback chain uses the available data of an Item when the data is accessed. Some users suggested that an empty label might be preferable to a potentially inaccurate placeholder. How can we balance the transparency of the system and concerns about data accuracy?

Your Feedback

Feedback from User:Epìdosis

I am answering according to the template, here is the result:

1. The default values are fundamental in reducing the redundancy in the termbox
2. They will significantly reduce the dimension of Wikidata, without any loss of content
3. Possible problems: see the two questions at point 6.
4. As of now I don't have other problems in mind.
5. Maybe just “default values” (or “default values for all languages”) would be fine; ideally, default values could link to Help:Default values for labels and aliases (at least in the first weeks) to help users understand it.
6. I have two doubts about the effectiveness of "mul" in reducing redundancy (which is its main goal):
   1. If I set A as label in "mul", will there be some mechanism that removes A from all labels and aliases in all other languages? Similarly, if I set B as alias in "mul", will there be some mechanism that removes B from all aliases in all other languages? If not, redundancy will not decrease (and a manual removal could be painfully long)
   2. If A is set as label in "mul", will it be technically impossible to save A as label or alias in all other languages? Similarly, if B is set as alias in "mul", will it be technically impossible to save B as alias in all other languages? If not, persons could just ignore "mul" and continue to add redundant labels and aliases as beforehands

Thanks for all this long work on "mul"! --Epìdosis 19:56, 15 February 2024 (UTC)

Thank you for your feedback, Epìdosis! Ideally, the guidelines and the changed user interface would be enough to convey the message. We should now test this in the real world, before we can plan stronger measures (at least from our end, maybe there are other things that people can already do to support this if needed). --Manuel (WMDE) (talk) 18:18, 22 February 2024 (UTC)

Feedback from User:Pigsonthewing

I just tried to use the LabelLister gadget to set a "mul" label on Dipelicus pseudofastigatus (Q30239450) and got an API error when I clicked "save". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:02, 29 July 2024 (UTC)

Crafting the Guidelines

Default values (mul) are a powerful new functionality, and should only be used in defined situations. We therefore need to explain well, when it is appropriate to use default values, and when not. Please make sure that the guidelines on Help:Default values for labels and aliases represent what you think is best for Wikidata before the release!

What Seems Important

• Stopping bots from creating new duplication of labels or aliases
• Helping editors with intuitive guidelines for usage of the feature.
• Strengthening (knowledge) equity for non-English languages.

Insights to Consider

We have the following insights to share that might be helpful for crafting the guidelines:

1. The biggest redundancy comes from Latin script languages. Default values in Latin script languages will therefore have the biggest impact at reducing redundancy. They also somewhat improve equity by allowing default languages other than English.
2. Default values in non-Latin script languages tested more negative with editors not familiar with the script (e.g. test case N2 using a Hebrew UI only showed the Korean default label).
   • If a non-Latin script language is used as a default value, this language will be seen by more people then before, but they can mostly not read it. This means that the additional people reached e.g. can't judge if a value is vandalism or not.
   • Placeholders could affect the experience on other Wikimedia projects negatively (some Wikipedia projects e.g. provide a built in search for Wikidata Items).
   • Some people in the usability test were uncomfortable with the idea of editing a value in a language that they don’t speak, especially in a different script.
   • All in all, if there was no label in the script of the own language, then a language fallback in Latin script was considered most useful compared to other scripts.
   • While the use of English as the only default is not the best practice in terms of diversity and inclusion, the practical benefits are limited for non-Latin languages: If a non-Latin script language is used as a default value, this language will be seen by more people then before, but they can mostly not read it. Also, many non-Latin languages already fall back to other languages in the same script.
3. The placeholders now visualize how the language fallback uses the available data in an Item. By itself, it is however still unclear, if identical values need to be re-entered” or not. Based on the usability test results, the placeholders might be perceived as suggestions and prompt the contributors to manually enter the value even if it is identical to the placeholder.
   • Some editors suggested that the placeholders have to be verified and published manually, even if the value is the same (e.g. with the intent to verify content in the case of diverging Transliterations).
   • There was the idea to send a warning or even disallow labels that are identical to the default values, see T306918. (This will however not be a feature in the initial release, and we have not made a decision about future releases.)

Titles

Under the section on usage is the line:

• Scientific articles and version, edition or translation.

Since this is placed on a single line, I assume it should read:

• Scientific articles and version, edition or translation of scientific articles.

And this would clarify the meaning.

If some other meaning is intended, then: (a) Why is this on a single line? and (b) Where is there a test case or example?

I also note that the single example for this usage is not a scientific article, but is instead a scholarly article, which is not the same thing. So, some clarification is required besides the above issue. --EncycloPetey (talk) 01:49, 6 January 2025 (UTC)

Discussion

Fix proposal

I have an idea to add checkboxes to each language which would affirm if that language can use mul or not. We will have economy of resources nevertheless (boolean/char/number vs. string) and correct labels with full info at the same time. --Infovarius (talk) 19:23, 22 December 2024 (UTC)

Adding a boolean to indicate that a label is the same as mul in fact does not reduce the amount of data compared with just adding the same label for all languages. Before we have the JSON "labels":{"en":{"language":"en","value":"Douglas Adams"},"en-gb":{"language":"en-gb","value":"Douglas Adams"}}. With mul we have "labels":{"mul":{"language":"mul","value":"Douglas Adams"}}, the shortest. But adding a boolean we will get "labels":{"mul":{"language":"mul","value":"Douglas Adams","sameAsMul":"false"},"en":{"language":"en","value":"","sameAsMul":"true"},"en-gb":{"language":"en-gb","value":"","sameAsMul":"true"}} which is in fact much longer. This information is also useless for data reusers outside of Wikidata contributors. The users don’t care about whether the term "Douglas Adams" in that Wikimedia Commons infobox is "en" or "mul", and they also don’t care whether "en" label is confirmed to be the same as "mul" label or not. So I completely reject this idea. Midleading (talk) 08:05, 16 January 2025 (UTC)

altLabels.js adding mul

I have hacked the script that allows easy assignment of the labels in other languages to your own (User:Joern/altLabels.js) as User:Vicarage/altLabels.js to add the mul label at the same time as the user's own language label. This is a proof of concept, I don't plan to support this version as I don't understand Javascript, and note that User:Joern has not made an edit for 7 years, so we are probably looking for a new home for a supported version. Vicarage (talk) 08:26, 23 December 2024 (UTC)

No fallback/placeholder for en-us -> en

Canadian English (en-ca) and British English (en-gb) correctly show the plain English (en) fallback value in their placeholders when it exists, but for some reason American English (en-us) doesn't. Can this be fixed? --NoInkling (talk) 04:02, 16 January 2025 (UTC)