I've been looking at this bug for sometime now and it's surprising that I've not yet been able to get it working as desired. Has anyone ever tried looked at this ?

I'm pretty sure the "This field is required." text is our 'required-field' message. That could be tested by tweaking that message locally to see if it does indeed change in the default English. It is usually added in InputWidget's validationRules computed property. I see that it is also present in EditTool.vue as the requiredRule value in that component's data() generator. I'm not sure that the message there is actually used now, but it being in a data() factory does match up with other locale switching issues @Slst2020 has found.

I also see in RegisterToolUrl.vue that a bare string of 'This field is required' is being used, and also from a data() factory!

In T298234#7637971, @bd808 wrote:

I'm pretty sure the "This field is required." text is our 'required-field' message. That could be tested by tweaking that message locally to see if it does indeed change in the default English. It is usually added in InputWidget's validationRules computed property. I see that it is also present in EditTool.vue as the requiredRule value in that component's data() generator. I'm not sure that the message there is actually used now, but it being in a data() factory does match up with other locale switching issues @Slst2020 has found.

I also see in RegisterToolUrl.vue that a bare string of 'This field is required' is being used, and also from a data() factory!

This is definitely part of the problem @bd808, but not all. When I experimented with this, I couldn't get it to work for the inputWidget fields even though validationRules get recaculated after locale change. It seems like vuetify form fields take a snapshot of the validation messages whenever validation is performed, and only changes the message after validation is rerun. The problem is that since there is no way ("or is there? I haven't been able to find any") of knowing if a field have been touched or not in vuetify, rerunning form validation after locale change will trigger validation error even for fields that haven't been touched before. Obviously there should be a way around this. Just haven't been able to find it yet.

Figure out a fix for this yesterday. The problem Is that once validation has been called, the text string displayed is inserted into the dom and can't be changed until another validation is called or page is reloaded. Since locale change doesn't trigger form revalidation (and trying to revalidate on locale change programmatically triggers validation of other untouched fields as well, so it's undesirable), their is no easy way to make the field react to the change of locale. This can be solved by using slots and only passing the translation key to the validation rule.

//slot
<template #message="{ message }">
	{{ parseFieldMessage(message) }}
</template>

  methods: {
        parseFieldMessage(message) {
            try {
                return this.$t(...JSON.parse(message));
            } catch {
                return this.$t(message);
            }
        }
    }

validationRules() {
       ..........
      if ( schema.maxLength ) {
            rules.push(
	    ( v ) => ( v || '' ).length <= schema.maxLength || JSON.stringify(['charslimit', [ schema.maxLength ] ])
	 );
	}
     return rules;
},

After I've gone a bit far in fixing this however, I wonder if it's worth it? I mean it's not often that we see users change locale after they've inputted text in form fields. I started to think about how important this is because it involves not only the change of how field validation rules work but also hints, et al. I will check-in with the team today to know what everyone thinks before proceeding.

Change 757788 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):

[wikimedia/toolhub@main] ui: Fix Minor UI bugs

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

In T298234#7656874, @Raymond_Ndibe wrote:

Figure out a fix for this yesterday. The problem Is that once validation has been called, the text string displayed is inserted into the dom and can't be changed until another validation is called or page is reloaded. Since locale change doesn't trigger form revalidation (and trying to revalidate on locale change programmatically triggers validation of other untouched fields as well, so it's undesirable), their is no easy way to make the field react to the change of locale. This can be solved by using slots and only passing the translation key to the validation rule.

//slot
<template #message="{ message }">
	{{ parseFieldMessage(message) }}
</template>

  methods: {
        parseFieldMessage(message) {
            try {
                return this.$t(...JSON.parse(message));
            } catch {
                return this.$t(message);
            }
        }
    }

validationRules() {
       ..........
      if ( schema.maxLength ) {
            rules.push(
	    ( v ) => ( v || '' ).length <= schema.maxLength || JSON.stringify(['charslimit', [ schema.maxLength ] ])
	 );
	}
     return rules;
},

After I've gone a bit far in fixing this however, I wonder if it's worth it? I mean it's not often that we see users change locale after they've inputted text in form fields. I started to think about how important this is because it involves not only the change of how field validation rules work but also hints, et al. I will check-in with the team today to know what everyone thinks before proceeding.

After the meeting today, the team agreed not to go too far into this rabbit hole but instead fix other minor i18n related bugs and call it a day. This is because though this issue exists, it doesn't cause any harm and you have to really go out of your way to discover it. It is not worth the trouble of adding unnecessary entropy to our codebase.

Change 757788 merged by jenkins-bot:

[wikimedia/toolhub@main] ui: Fix Minor UI bugs

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

Change 770638 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[operations/deployment-charts@master] toolhub: Bump container version to 2022-03-15-002555-production

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

Change 770638 merged by jenkins-bot:

[operations/deployment-charts@master] toolhub: Bump container version to 2022-03-15-002555-production

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