Bug 1919230 Comment 10 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(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](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#input_types)), 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, Google Chrome does not translate these text-like input values, so I am going to leave them out for the sake of being cautious. We can always add those in if there is an expressed desire to do so. 

The "other" group of input types should decidedly **_not_** be translated. 

I will update this patch stack to 

1) Respect the no-translate rules for attribute translation (as I've already implemented)
2) Only translate `<input>` elements that match the specified types.
(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](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#input_types)), 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 

1) Respect the no-translate rules for attribute translation (as I've already implemented)
2) Only translate `<input>` elements that match the specified types.

Back to Bug 1919230 Comment 10