Hi @Sarai-WMDE, from all the suggestions "default values for all languages" seems most self explanatory. Could you please check if this is at least tolerable from the design perspective?

That's definitely explanatory, but also too long of a copy and the "all" bit doesn't really apply to 100% of the scenarios. What about something like "multiple languages default"?

I think "default values for all languages" is more correct, as the values are used as the defaults for all languages, not just some/multiple.

Would you like to veto this from the UX perspective because of the long copy? If so, then I would go with "default values" (also correct, but likely less self explanatory).

Sorry for the late reply. Not vetoing anything, but encouraging us to maybe ask for feedback on the options? Would be great to hear other ideas/opinions from team members too.

I think that besides the length, and the potential issue with the "all" bit in "Default values for all languages" (it reflects how the system works, but it might not be aligned with the use case or the users' intention), there's also the fact that the language code ("multiple languages") is not mentioned/referenced in that copy.

We know that "default values" wasn't of great support for users trying to understand how MUL works, so I would discard that as an option.

DL;DR: No veto from UX, so we are good for the initial release from my side.

I think that besides the length, and the potential issue with the "all" bit in "Default values for all languages" (it reflects how the system works, but it might not be aligned with the use case or the users' intention)

What do you mean with "it might not be aligned with the use case or the users' intention"? Maybe we have a different understanding of what a default is? The dictionary says that in the software context it's "a selection automatically used by a program in the absence of a choice made by the user" (see here for Spanish). So it should mean that the value specified is used for all languages that don't have a dedicated value specified. If users are setting a "default value for all languages" it is important that their intention aligns with this meaning.

there's also the fact that the language code ("multiple values") is not mentioned/referenced in that copy.

My original intention was to mention the language code ("mul") to create a bridge for the API users. After the user tests I realized that this was not a good idea. Not referencing "multiple languages" is a plus from my side, as it does not explain to users what this does.

Not vetoing anything, but encouraging us to maybe ask for feedback on the options? Would be great to hear other ideas/opinions from team members too.

I asked most people that worked on this feature (in the team, department, and community) about this and there were no strong opinions in any direction, so personally, I have no need for additional input on this from the team. I will however have an open ear about what the wider community says about this after we switch it on. If you want to ask additional people before that, it is important to thoroughly explain them the context, otherwise the feedback will not be valuable.

We know that "default values" wasn't of great support for users trying to understand how MUL works,

Do we know that? We only tested "default values (mul)" as far as I remember.

so I would discard that as an option.

In any case we seem aligned that this is the less optimal solution of the two, so I'll go with that for the initial release.

The dictionary says that in the software context it's "a selection automatically used by a program in the absence of a choice made by the user" (see here for Spanish).

I understand that you were probably just trying to help inform the discussion, but that last message could be interpreted as quite condescending. I specially don't appreciate the link to an entry in Spanish and the implications that one could ascribe to such a gesture.

Moreover, I believe that you could infer from my previous messages that I was working with that same definition in mind when I said that the suggested copy "reflects how the system works". Using copy that transparently communicates the system's logic in a user-friendly way is of course recommended. All I meant (and failed) to point out is how the diversity of scenarios due to the interaction of MUL with the language fallback chain, combined with the users' intention to make sure, in some cases, that the right translations are provided and not overridden, could make this copy sound potentially disruptive. The suggestion is not incorrect, I never meant that or mentioned it wasn't an acceptable option, was just looking for acknowledgement of that potential/assumed perception from the users' side. I apologize for not conveying that point of view in a clearer way.

If users are setting a "default value for all languages" it is important that their intention aligns with this meaning.

But yes, again, I never meant to block or object to your proposal, just offer a different perspective. Let's use your suggestion and hope that, maybe instead, the copy's meaning aligns with the user's understanding and intentions.

I will however have an open ear about what the wider community says about this after we switch it on.

That's all I would encourage. Thanks for making sure we offer a listening ear to the community.

Thank you for the clarification, Sarai! I apologize if the link was not helpful. I had just looked this up in German myself, after I realized that the differentiation between "default" and "fallback" in English may not be as clear cut in other languages. I wanted to understand better what your point was and therefore tried to make things clearer and avoid misunderstandings. In any case this is unfortunately something that we will have to consider when the copy this gets translated.

Change 1012614 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Update text copy for 'mul' / default values for all languages

https://gerrit.wikimedia.org/r/1012614

I've made most of the changes to the copy per the ticket. In the case of New Item / New Property, the prompts in the form are now ungrammatical:

Should we change that? Should we change the formulation just for 'mul' as a special case? Or should we find a formulation that works for all cases?

Hey @ArthurTaylor. Yes, we should definitely update all relevant copy. If there's a way to replace the whole message, I believe this could just say: "enter a default value for all languages", since the field label is already indicating what the value corresponds too. But let's see what @Manuel thinks.

Is there a way we can get an overview of all the (other) prompts that need to be adjusted? Happy to provide the alternative version for all of those.

In the case of New Item / New Property, the prompts in the form are now ungrammatical

Hi @ArthurTaylor, thank you for bringing this up! The status quo was already ungrammatical, so we are at least not making it worse. I am not sure if this could be solved via a general formulation that works for all cases, especially considering translations in all languages. So changing the formulation just for 'mul' as a special case sounds like a better option. If it does not significantly increase the complexity, I would be happy if you implemented it as a part of this task. Let me know if you have another idea!

In other places, at least in English, it says "Enter a label in default":

But that's only because the rest of the placeholder text wraps and disappears in the overflow. The full text is 'Enter a label in default values for all languages'

"enter a default value for all languages" sounds good to me - thanks @Sarai-WMDE . It does increase the complexity - I don't know how much yet. Will take a look and see if it's manageable.

Thank you @ArthurTaylor for looking into this and thank you @Sarai-WMDE for offering to provide the alternative versions!

So the special-casing doesn't seem too terrible, but the text is still too long to fit in the termbox:

Any smart ideas?

Hi @ArthurTaylor, both "enter a default label" and "enter a default value" would work from my side. The first option would be more in line with the other rows.

Change 1013266 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Add special-case labels for input form placeholders for mul

https://gerrit.wikimedia.org/r/1013266

Change #1012614 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Update text copy for 'mul' / default values for all languages

https://gerrit.wikimedia.org/r/1012614

Change #1013266 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add special-case labels for input form placeholders for mul

https://gerrit.wikimedia.org/r/1013266