347515 - Should form elements' controls be in document's language?

Status: NEW

(Core :: Layout: Form Controls, enhancement)

Description

[Behnam Esfahbod [:zwnj]]

When a form element (i.e. Submit button) has default value, its bidi direction and alignment should be as firefox's locale is.

Another solution (not good, but solves this problem) is to set the value from the website's locale.

Comment 1

[Behnam Esfahbod [:zwnj]]

Attachment: Sample screenshot

The word in the button is "Browse...".

Comment 2

[Simon Montagu :smontagu]

I'm not 100% sure that setting the directionality of an element in a web page based on the locale direction is desirable. (I assume that the web page itself is left-to-right, otherwise the problem wouldn't arise). Maybe it would be better to add a RIGHT TO LEFT MARK (\u200F) at the end of the localized text?

Comment 3

[Axel Hecht [:Pike]]

Looking at the screenshot, I'd rather blame <input type="file"> to have bidi issues here.

Though I have no idea what the expected behaviour of a RTL "Browse..." translation in a LTR webpage should be.

Comment 4

[Behnam Esfahbod [:zwnj]]

Thanks Simon, that works.  Now I should find all form elements and use RLM or RLE/PDF to fix them.

Alex, it should look like "...esworB" which is "esworB..." right now.

But let's follow the second idea.  Should browser show HTML elements (i.e. form elements) in documents language, instead of desktop language?  I'm going to take a look at HTML 4.x and XHTML, but AFAIR they haven't said anything about it.

Comment 5

[Behnam Esfahbod [:zwnj]]

I fixed dom/chrome/layout/HtmlForm.properties and it works.

Comment 6

[Simon Montagu :smontagu]

(In reply to comment #3)
> Looking at the screenshot, I'd rather blame <input type="file"> to have bidi
> issues here.

Axel, I'm not sure what you mean by this. Can you rephrase?

Comment 7

[Behnam Esfahbod [:zwnj]]

Attachment: Fixed Bidi problem. Wrong language.

As you can see, it's an English web page with Persian("Browse...") in form's file update element.

Comment 8

[Behnam Esfahbod [:zwnj]]

This is all I found in HTML 4.01 spec:
"""
file
    Creates a file select control. User agents may use the value of the value attribute as the initial file name.
"""

Beside it's security problem, I think there's no way to set the "Browse..." label in HTML at all.  So all user can do is to set the language of the INPUT object, and of course she wants to get the button in that language.

Comment 9

[Behnam Esfahbod [:zwnj]]

That's better to use documents language when it is installed on the system.  Then my English bugzilla page will have "Browse..." button in English.

Of course it is not necessary to support all HTML element translations in all builds.

Comment 10

[Axel Hecht [:Pike]]

Simon, is it a bug or a feature that '...' following RTL text is displayed LTR?

Regarding using the webpage language to display HTML forms content, that's an interesting idea. It'd be challenging from a build POV, and it should probably be restricted to accept_lang. I doubt that download size is an issue.

Moving out to Core Layout: Form Controls for further discussion. Maybe a newsgroup post would be appropriate to flesh out the design options.

Comment 11

[Simon Montagu :smontagu]

(In reply to comment #10)
> Simon, is it a bug or a feature that '...' following RTL text is displayed LTR?

A feature. Neutral characters like ... at the end of a line follow the base direction of the paragraph, which is LTR by default in a LTR page.

> Regarding using the webpage language to display HTML forms content, that's an
> interesting idea.

I suspect that it would be moot most of the time. The examples here are from bugzilla.m.o, which still doesn't declare its character encoding, let alone its language.

Comment 12

[Tsahi Asher]

in the hebrew l10n, i did what smontagu suggested in comment 2. so i have hebrew buttons on english web pages, it doesn't bother me much.

i assume that anyone using a hebrew localized browser will know how to read these buttons, so i don't think it's a problem.

Comment 13

[Axel Hecht [:Pike]]

Does bug 346726 have any impact on this, or is that one fixing an orthogonal problem?

Comment 14

[Simon Montagu :smontagu]

Orthogonal. Bug 346726 is about the positioning of the file control's text input and button. This is about the ordering of the text on the button.

Comment 15

[Behnam Esfahbod [:zwnj]]

(In reply to comment #12)
> in the hebrew l10n, i did what smontagu suggested in comment 2. so i have
> hebrew buttons on english web pages, it doesn't bother me much.

I fixed Persian translation too.  As you can see in the second attachment, it works well.

> i assume that anyone using a hebrew localized browser will know how to read
> these buttons, so i don't think it's a problem.

It's not a localization problem anymore.  What I request now is to show form elements' texts in language of document, maybe only when it *is* in accept-language list.


(In reply to comment #14)
> input and button. This is about the ordering of the text on the button.

We will have the ordering problem, only if we don't want to use HTML language for test of such buttons.  And looking at accept-language list may cause ordering problem again...

Comment 16

[Boris Zbarsky [:bzbarsky]]

Why would we take the document language over the user's preferred language, exactly???

If that's what the bug is about, I think we should wontfix it.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Agree on the wontfix.

But there's probably stuff we can do to improve file controls in the bidi case.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Oh, absolutely.  Given the previous history in the bug (in particular the attempts to steer away from that), perhaps those should go in separate bugs...

Comment 19

[Niro]

IMO, fixing bug 352054 can solve the bidi problems.