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)

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.)

Discussion

Clear name

What would be a clear name to refer to multiple languages in the termbox table?

"default label". The label being present in the lower languages as greyed-out text shows that it applies as the default label to all languages.

It should also be placed at the top of the termbox if not overridden, not the bottom. If overridden, it should be placed second to the current language label. Lectrician1 (talk) 14:07, 12 February 2024 (UTC)

"Multiple

Languages"

placed before all the individual language entries. It will encourage its use

I assume that will be taken to be latin script version, as there is no other script that serves anything like the number of languages

Can you highlight when the individual language entries match the multiple one, to encourage their removal for simplification? Vicarage (talk) 17:24, 12 February 2024 (UTC)

About the scripture: This is a community discussion, but yes, the tests showed that default values should in most cases only be used for Latin scripture. I already changed the draft of the help page to reflect this insight.

About the order in the termbox: For usability, it is important that the position of the default values is consistent. We avoided the top position, to reflect that in most cases, default values will not be applicable.

Also thank you for your other feedback and ideas, Vicarage and Lectrician1! --Manuel (WMDE) (talk) 18:18, 22 February 2024 (UTC)

mandatory language pre-filled as "mul"

When a property has a mandatory language, could "mul" be pre-entered in the box to encourage its use over parochial choices like "en". It would also promote its availability, as I'm sure many have never heard of it Vicarage (talk) 17:27, 12 February 2024 (UTC)

tbh, it would be nice if all the 'special' codes appeared first (like zxx or mis). Arlo Barnes (talk) 22:42, 12 February 2024 (UTC)

Thank you for your feedback, Arlo Barnes! --Manuel (WMDE) (talk) 18:18, 22 February 2024 (UTC)

Approve label from other languages:

How do you see this feature (see User:Joern/altLabels.js) working. Would it write to mul, or your personal language. The former would encourage adoption of the system Vicarage (talk) 17:49, 12 February 2024 (UTC)

I agree, maybe a gadget could add for each label a little button that, if clicked, copies that label to "mul", if "mul" is not already set. --Epìdosis 19:59, 15 February 2024 (UTC)

Help:Mul language code

I discovered the existence of this other (older) page. Could its material be moved inside this one and, afterwards, could it be redirected to this one? Having both could be confusing. Thanks! --Epìdosis 16:30, 13 February 2024 (UTC)

Done, thx! --Manuel (WMDE) (talk) 17:56, 22 February 2024 (UTC)

Name translation

Currently, the name in the termbox ("default values for all languages") remains the same regardless of the interface language. Could you please confirm if it will be translated/translatable? Ayack (talk) 15:32, 22 April 2024 (UTC)

Default value should be more visible

If the default value is not displayed in the top position, I believe it should be made more visible. This could include using bold or italic text for the name, and/or applying a light grey background. Ayack (talk) 15:40, 22 April 2024 (UTC)