Firefox 130 translates radio and checkbox input values despite of translate=no attribute
Categories
(Firefox :: Translations, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | unaffected |
firefox130 | --- | wontfix |
firefox131 | --- | fixed |
firefox132 | --- | fixed |
People
(Reporter: cweiss, Assigned: nordzilla)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(4 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-release+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-release+
|
Details | Review |
Steps to reproduce:
User agent string: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0
Also happens with Windows version.
Here's a simple page with a test form:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Simple Form</title>
</head>
<body>
<h1>Simple POST Form to test potential Firefox translation bug</h1>
<form action="test.php" method="POST">
<label>
<input type="radio" name="option" value="option_one" translate="no">
This is option 1
</label><br>
<label>
<input type="radio" name="option" value="option_two" translate="no">
And this is option 2
</label><br>
<label>
<input type="checkbox" name="checkbox" value="checkbox_value" translate="no">
Let's also try with a checkbox
</label><br><br>
<input type="submit" value="Submit">
</form>
</body>
</html>
Use the "Translate page" function to translate from English to German, then submit the form.
Actual results:
Input values are translated/changed on submit:
"option_one" becomes "option-one" (notice the dash instead of underscore) and
"checkbox_value" becomes "Checkbox-Wert".
The translate="no" attribute on the inputs is entirely ignored. If I add the attribute to the <form> tag, at least the labels are not translated, but the values still are.
Expected results:
Checkbox and radio values should not be changed on submit.
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Translations' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Reporter | ||
Comment 2•2 months ago
|
||
Also the "Submit" button gets translated to "Untermit", which makes no sense. "Absenden" or "Abschicken" would be correct.
Assignee | ||
Comment 3•2 months ago
•
|
||
Hi Clemens Weiß, thanks for submitting this bug!
I do believe that this is a genuine defect in which we are respecting no-translate attributes with regard to a node's text content, but not with regard to its other translatable attributes.
I'll write a patch to fix this and add an automated test case to cover this behavior.
Thanks for taking the time to create an example HTML document. That was super helpful!
(In reply to Clemens Weiß from comment #2)
Also the "Submit" button gets translated to "Untermit", which makes no sense. "Absenden" or "Abschicken" would be correct.
Unfortunately this is beyond the scope of this patch as it relates to the quality of the output from the English-to-German machine-learning model.
We do hope to continue to iterate on the quality of our models as well as release newly trained language models. Any issues related to model translation quality should be reported here. We appreciate the feedback!
Assignee | ||
Comment 4•2 months ago
|
||
Fixes areas within translations-document.sys.mjs that are not compatible
with the newly enable no-shadow rule for ESLint.
Assignee | ||
Comment 5•2 months ago
|
||
Ensures that nodes that should be excluded from translations due to
having attributes such as translate="no"
or class="notranslate"
are excluded from attribute translation. Previously, we were excluding
them from translating their text content, but would still translate
other attributes such as value
.
Depends on D222518
Updated•2 months ago
|
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
Comment 6•2 months ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Reporter | ||
Comment 7•2 months ago
|
||
Hi Erik Nordin, thanks for taking care of this!
In my opinion the value of these radio/checkbox inputs should never be translated, because they are not shown to the user. Instead they are defined by the website/application, which usually breaks if it receives an unexpected value.
I guess the same applies to select boxes...
Comment 8•2 months ago
|
||
In my opinion the value of these radio/checkbox inputs should never be translated, because they are not shown to the user. Instead they are defined by the website/application, which usually breaks if it receives an unexpected value.
Yeah I agree with this, and was an oversight on the original implementation.
Assignee | ||
Comment 9•2 months ago
|
||
(In reply to Greg Tatum [:gregtatum] from comment #8)
In my opinion the value of these radio/checkbox inputs should never be translated, because they are not shown to the user. Instead they are defined by the website/application, which usually breaks if it receives an unexpected value.
Yeah I agree with this, and was an oversight on the original implementation.
Same, agreed!
I will modify the patches to ensure that translate="no"
is respected, and that the [value]
attribute is not translated ever for <input>
elements.
Assignee | ||
Comment 10•2 months ago
•
|
||
(In reply to Erik Nordin [:nordzilla] from comment #9)
(In reply to Greg Tatum [:gregtatum] from comment #8)
In my opinion the value of these radio/checkbox inputs should never be translated, because they are not shown to the user. Instead they are defined by the website/application, which usually breaks if it receives an unexpected value.
Yeah I agree with this, and was an oversight on the original implementation.
Same, agreed!
I will modify the patches to ensure that
translate="no"
is respected, and that the[value]
attribute is not translated ever for<input>
elements.
Okay, I've done some further investigation and come up with a plan.
Background
Bug 1878710 introduced translating all value
attributes for <input>
elements, so I am going to mark that as the regressor.
I believe the original intent for including <input>
elements in this bug was to translate button text, which is completely valid. This did, however, introduce the side effect of translating value
attributes for radio buttons and checkboxes as described by this bug.
Plan of Action
I audited all of the <input>
types (MDN), and grouped them into three categories:
Button-like <input> types:
- button: A push button with no default behavior.
- image: A graphical submit button.
- reset: A button that resets the contents of the form to default values.
- submit: A button that submits the form.
Text-input-like <input> types:
- datetime (Deprecated): A control for entering a date and time based on UTC time zone.
- email: A field for editing an email address.
- password: A single-line text field whose value is obscured.
- search: A single-line text field for entering search strings.
- tel: A control for entering a telephone number.
- text: The default value; a single-line text field.
- url: A field for entering a URL.
Other <input> types:
- checkbox: A check box allowing single values to be selected/deselected.
- color: A control for specifying a color.
- date: A control for entering a date.
- datetime-local: A control for entering a date and time.
- file: A control that lets the user select a file.
- hidden: A control that is not displayed but whose value is submitted to the server.
- month: A control for entering a month and year.
- number: A control for entering a number.
- radio: A radio button for selecting a single value out of multiple choices.
- range: A control for entering a number where the exact value is not important.
- time: A control for entering a time value.
- week: A control for entering a week-year number and a week number.
Ultimately, I think it's clear that we want to continue translating all of the button-like <input>
types. button
, reset
, and submit
all use the value
attribute for their text, however the image
type uses alt
if the image cannot be displayed.
We could, in theory, translate default values for types such as text
and search
. This would only apply to the pre-populated value within the markup, and, in my testing, any manually inputted value does not get translated. However, populating default values would be more appropriate for the placeholder
attribute, which we do translate.
The "other" group of input types should decidedly not be translated.
I will update this patch stack to
- Respect the no-translate rules for attribute translation (as I've already implemented)
- Only translate
<input>
elements that match the specified types.
Updated•2 months ago
|
Assignee | ||
Comment 11•2 months ago
|
||
I mistagged this before. ESR-128 is not affected.
Comment 12•2 months ago
|
||
I agree with this plan. Thanks for writing it out.
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 13•2 months ago
|
||
Comment 14•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c7c79b33d74a
https://hg.mozilla.org/mozilla-central/rev/fc9e1fc232d0
Assignee | ||
Comment 16•1 month ago
|
||
Fixes areas within translations-document.sys.mjs that are not compatible
with the newly enable no-shadow rule for ESLint.
Original Revision: https://phabricator.services.mozilla.com/D222518
Updated•1 month ago
|
Assignee | ||
Comment 17•1 month ago
|
||
Reworks the structures behind attribute translations, allowing us to further constrain
for which types of elements certain attributes are considered translatable.
This patch also improves the algorithm to fix the correctness of attribute translations
respecting class="notranslate"
and translate="no"
et al.
Original Revision: https://phabricator.services.mozilla.com/D222519
Depends on D222518
Depends on D224332
Updated•1 month ago
|
Comment 18•1 month ago
|
||
release Uplift Approval Request
- User impact if declined: The
value
attributes will be translated for all<input>
elements. For button-like<input>
elements this makes sense as it will translate the text on the button. For other<input>
elements such asradio
, this will translate the non-user-visiblevalue
that is sent to the database upon submit, which is not intended. - Code covered by automated testing: yes
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: N/A
- Risk associated with taking this patch: Low risk
- Explanation of risk level: This patch is well tested in automation, and the fixes have been verified in the beta build by the contributors who reported the defect.
- String changes made/needed: None
- Is Android affected?: yes
Updated•1 month ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Comment 20•1 month ago
|
||
uplift |
Description
•