522913 - Reimplement access to context-specific language properties

Status: RESOLVED WONTFIX

(Firefox :: Menus, enhancement)

Description

[Gordon P. Hemsley [:GPHemsley]]

The landing of bug 513147 means that the only way to find out what language a particular selection of text is in was removed from Firefox. You used to be able to right-click on a selection of text (e.g. <p lang="en-US">This is American English.</p>) and find out what language it was in (and from region).

Bug 356038 was intended to expand upon this access by including all the new data allowed by BCP 47: more languages, more locations, scripts, etc. However, the removal of the Properties context menu meant that that expanded code had no place to live.

I recommend that this data be exposed somewhere. I honestly don't care where, as long as it's available (outside of the source code viewer). (This request is along the same lines as bug 517902.)

Comment 1

[u88484]

Could you please attach a minimized testcase or at the very least, link to a real world page that you used to reproduce this on?  And also explaining why figuring out the selected language was useful may also help you get something done with this bug.

Comment 2

[WulfTheSaxon [:Wulf]]

For starters, here's the relevant spec: http://www.w3.org/TR/html40/struct/dirlang.html#h-8.1 and/or http://dev.w3.org/html5/spec/Overview.html#the-lang-and-xml:lang-attributes

And here's a page from the official HTML test suite that uses the lang attribute (although the test has nothing to do with the behavior being discussed in this bug): http://www.w3.org/MarkUp/Test/HTML401/current/tests/8_1-BF-01.html

Comment 3

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #1)
> Could you please attach a minimized testcase or at the very least, link to a
> real world page that you used to reproduce this on?  And also explaining why
> figuring out the selected language was useful may also help you get something
> done with this bug.
Really?

For starters, any properly-written XHTML page will have used the lang and/or xml:lang attributes.

Not to mention all of the information available in bug 356038, which I already linked to in comment 0. In particular, the test case is attachment 397553 [details].

Comment 4

[u88484]

(In reply to comment #3)
> (In reply to comment #1)
> > Could you please attach a minimized testcase or at the very least, link to a
> > real world page that you used to reproduce this on?  And also explaining why
> > figuring out the selected language was useful may also help you get something
> > done with this bug.
> Really?
Really.

> For starters, any properly-written XHTML page will have used the lang and/or
> xml:lang attributes.
> Not to mention all of the information available in bug 356038, which I already
> linked to in comment 0. In particular, the test case is attachment 397553 [details].

It makes a dev more likely to take a look at a bug and easier for them to decide to fix it if you provide all the data needed to make a decision.  Making a dev hunt down relevant pages isn't helpful or a good use of their time.

Comment 5

[u88484]

A reduced test case is still needed and a description of why you think this information is even useful to the majority of users anyway.

Comment 6

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Reduced test case

Here you go.

Comment 7

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #6)
> Created an attachment (id=407007) [details]
> Reduced test case
> 
> Here you go.
Thank you. :)

Also note that, in addition to finding out that the text is marked 'en-US', there should also be a way to find out that that means 'English (United States)'. (Bug 356038 is intent on improving the processing of more complicated tag combinations.)

Comment 8

[u88484]

Readin the W3.org links you provide only talks about user agent and spell checkers making use of this.  More specificall and as a quote:
Assisting search engines 
Assisting speech synthesizers 
Helping a user agent select glyph variants for high quality typography 
Helping a user agent choose a set of quotation marks 
Helping a user agent make decisions about hyphenation, ligatures, and spacing 
Assisting spell checkers and grammar checkers 

What's the use of language used being exposed in a window?  Seems like a huge waste of code when the user should have an interaction with the this.

Also, right now you have to select the text, right-click, select 'View Selection Source' to see what language was used.  What is the difference in that rather then select the text, right-click, select 'Properties'.  It is just as easy to figure this out without having in a sense duplicate code to view the information that a regular user has absolutely no use in.

Comment 9

[u88484]

Sorry for the all kinds of fail in the last post.  Just wanted to fix this:
"Seems like a huge waste of code when the user should have an interaction with the this."
Seems like a huge waste of code when the user should not have any interaction with this.

Comment 10

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #8)
> What's the use of language used being exposed in a window?  Seems like a huge
> waste of code when the user should not have any interaction with this.
What's the use of the Page Info window showing the type, render mode, or
encoding? That's a lot less useful to a regular person than knowing what
language the text that they're reading is in.

> Also, right now you have to select the text, right-click, select 'View
> Selection Source' to see what language was used.  What is the difference in
> that rather then select the text, right-click, select 'Properties'.  It is just
> as easy to figure this out without having in a sense duplicate code to view the
> information that a regular user has absolutely no use in.
Just like every other bit of information in the Properties menu, you do not
have to select any text in order to get the language information on it.
Right-clicking in the right place is all that is required.

And it could be very tedious finding out the language of something by only
looking at its source code. The selection source is most likely not going to
help you, as chance are it will have been inherited. You would have to find the
location in the code where the lang attribute is try to see if it cascades down
to whatever selection of text you were wondering about. Even then, you would
only find out the code (e.g. en-US). Without the Properties dialog box (or some
alternate display method), it would be your responsibility to parse that and
find out that it means "English (United States)". And this particular example
is a rather easy one—it can get exponentially more difficult to determine what
any given subtag combination could mean, especially if the numerical UN region
codes are involved.

Comment 11

[Johnathan Nightingale [:johnath]]

(In reply to comment #10)
> (In reply to comment #8)
> > What's the use of language used being exposed in a window?  Seems like a huge
> > waste of code when the user should not have any interaction with this.
> What's the use of the Page Info window showing the type, render mode, or
> encoding? That's a lot less useful to a regular person than knowing what
> language the text that they're reading is in.

However the debate evolves on the subject of this feature, I'd like to ask people to avoid this kind of non-sequitur. Let me be clear: the test for a particular feature is never going to be "can you name an existing feature that you find less useful?" This feature is useful or not, on its merits.

If there's some other feature you think we should remove, file the bug, put [killthem] in the whiteboard, cc me if you like. But the disposition of that hypothetical bug is entirely independent of the decision we make on this feature; trying to tie the two together is worse than irrelevant, it actively works against your aims by creating distraction, and generating replies like this one.

Comment 12

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > What's the use of language used being exposed in a window?  Seems like a huge
> > > waste of code when the user should not have any interaction with this.
> > What's the use of the Page Info window showing the type, render mode, or
> > encoding? That's a lot less useful to a regular person than knowing what
> > language the text that they're reading is in.
> 
> However the debate evolves on the subject of this feature, I'd like to ask
> people to avoid this kind of non-sequitur. Let me be clear: the test for a
> particular feature is never going to be "can you name an existing feature that
> you find less useful?" This feature is useful or not, on its merits.
Fair enough.

> If there's some other feature you think we should remove, file the bug, put
> [killthem] in the whiteboard, cc me if you like. But the disposition of that
> hypothetical bug is entirely independent of the decision we make on this
> feature; trying to tie the two together is worse than irrelevant, it actively
> works against your aims by creating distraction, and generating replies like
> this one.
That's the thing, though. I'm not a fan of the concept itself of removing features just for the heck of it. I don't want to use the [killthem] whiteboard tag in any bug. It may be outside the scope of this bug, but, from my perspective, the logic for removing the Properties context menu item was not strong enough. And just because all the up-and-ups agreed to it doesn't make it logical.

But all that doesn't matter to me if the language data is returned somewhere, because that's mostly what I used the Properties dialog box for. (I think other people have their own points for the return of things like the link target and title contents, but they can make the case for those themselves, as they don't affect me all that much.)

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #12)
> That's the thing, though. I'm not a fan of the concept itself of removing
> features just for the heck of it. I don't want to use the [killthem] whiteboard

Conversely, I am not a fan of adding or maintaining features just for the heck of it. Features should carry merit for the majority portion of our user base, or be requirements for smaller yet significant minorities. 

At all times this value should be weighed against the costs. There *is* a cost to an additional context menu item, in terms of complexity, code maintenance, translation, and user time spent determining if that is the target they wish to hit (see Hicks' Law)

> tag in any bug. It may be outside the scope of this bug, but, from my
> perspective, the logic for removing the Properties context menu item was not
> strong enough. And just because all the up-and-ups agreed to it doesn't make it
> logical.

It is, indeed, outside of the scope of this bug.

Comment 14

[Mike Connor [:mconnor]]

I think it's pretty clear from the specs that this is an implementation detail, not a user-centric piece of metadata.  I do think that this could be marginally useful, but I also think that marginally useful isn't sufficient for a core feature.  Keeping within the scope of this bug (is this feature something we should (re)implement?) it's clearly a WONTFIX.

Comment 15

[Nicolas Barbulesco]

(In reply to Kurt Schultz (supernova_00) from comment #8)

> Also, right now you have to select the text, right-click, select 'View
> Selection Source' to see what language was used.  What is the difference in
> that rather then select the text, right-click, select 'Properties'.

The differences are these ones :

1) The user has to know s/he can find the language in the source.
2) The user has to know how to read HTML. Is Firefox meant for Web users or only for Web authors ?
3) The user has to know that "eu" means "basque language". Is Firefox meant for ISO-639 standards specialists or for human people ?