Page MenuHomePhabricator

Consider using content language for "html lang", rather than interface language
Open, LowestPublicFeature

Description

0) Open Chromium and, in one tab, chrome://translate-internals/#detection-logs

  1. Visit https://fi.wikipedia.org/wiki/Opiskelijaraha?uselang=it and https://fi.wikipedia.org/wiki/Wikipedia:Etusivu?uselang=it (or set interface language to "it" and drop the uselang), save their HTML and alter '<html lang="it"' to '<html lang="fi"', open the HTML in the same browser.

I. Expected: the article content is recognised as "fi" locale and appropriately translated (or not) by Chromium according to my preferences.
II. Observed: the result is rather random depending on the amount of text in content vs. interface, but in general the interface language prevails because it's in the general html lang attribute. In the log something like this can be seen:

[

{
    "adopted_language": "it",
    "cld_language": "it",
    "content_language": "fi",
    "html_root_language": "it",
    "is_cld_reliable": true,
    "time": 1406157710650.132,
    "url": "https://fi.wikipedia.org/wiki/Opiskelijaraha?uselang=it"
},
{
    "adopted_language": "und",
    "cld_language": "it",
    "content_language": "",
    "html_root_language": "fi",
    "is_cld_reliable": true,
    "time": 1406158649658.846,
    "url": "http://koti.kapsi.fi/~federico/tmp/Opiskelijaraha-it.html"
},
{
    "adopted_language": "und",
    "cld_language": "fi",
    "content_language": "fi",
    "html_root_language": "it",
    "is_cld_reliable": true,
    "time": 1406159280979.992,
    "url": "https://fi.wikipedia.org/wiki/Wikipedia:Etusivu?uselang=it"
},
{
    "adopted_language": "und",
    "cld_language": "en",
    "content_language": "",
    "html_root_language": "fi",
    "is_cld_reliable": true,
    "time": 1406159369076.235,
    "url": "http://koti.kapsi.fi/~federico/tmp/Etusivu-it.html"
}

]

See also https://code.google.com/p/chromium/issues/detail?id=254330#c6 and https://code.google.com/p/chromium/issues/detail?id=95394#c20 ; per https://code.google.com/p/chromium/issues/detail?id=95394#c6 it doesn't look likely that Chromium will be able to recognise language of page fragments any time soon.

Yet, we have some optimistic "lang" tagging like:

<html lang="it" dir="ltr" class="client-nojs">
<body class="mediawiki ltr sitedir-ltr ns-0 ns-subject page-Opiskelijaraha skin-monobook action-view">
<div id="globalWrapper">

		<div id="column-content">
			<div id="content" class="mw-body-primary" role="main">
				<div id="bodyContent" class="mw-body">
					<div id="contentSub" lang="it" dir="ltr"></div>
					<!-- start content -->
					<div id="mw-content-text" lang="fi" dir="ltr" class="mw-content-ltr">
					PAGE IS HERE
					</div>
				</div>
			</div>
		</div>
		<div id="column-one" lang="it" dir="ltr">
		BASICALLY ALL INTERFACE
		</div>

</body></html>

The interface is correctly tagged as "it" and the content as "fi", but they're both wrapped in a (false) html lang which trumps them.


Version: unspecified
Severity: enhancement

Details

Reference
bz68490

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 3:28 AM
bzimport set Reference to bz68490.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to Nemo from comment #0)

The interface is correctly tagged as "it" and the content as "fi", but
they're both wrapped in a (false) html lang which trumps them.

If that is happening somewhere, it is broken. The attribute closest to the content wins. That's how HTML works.

(In reply to Niklas Laxström from comment #1)

The attribute closest to the
content wins. That's how HTML works.

Thanks, I found a source: http://www.w3.org/TR/html401/struct/dirlang.html#h-8.1.2

Niklas pointed out that, if we removed or changed the general html lang attribute, then we could have some inner element with lang attribute missing (hence inherited incorrect). Chasing them one by one is not feasible.

Before filing this bug I failed to find one without its specific language information but it would need more inspection also with other skins and extensions. Maybe one of the "broad" divs can be used to tag all such items with less broad effects.

P.s.: The bug was tested with 35.0.1916.153 Russian Fedora (274914); the upstream links show they're aware of the problem (which may or not be filed clearly though) but don't plan to do something about it soon. I'll try to understand if the issue and use case are clear for them.

I'm not sure whether this is something we want to try to fix or just leave it to the upstream to figure out. Leaving open with lowest priority for now.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:14 AM
Aklapper removed a subscriber: wikibugs-l-list.

The html lang should be the same as the content language since that's the main page language.

On :sl, even though the page variables contain

"wgPageViewLanguage":"sl","wgPageContentLanguage":"sl", "pageLanguageCode":"sl","pageVariantFallbacks":"sl"

I get

<html lang="fr">

because I've set interface language to French in my user settings.

This has the major drawback of disabling browser page (auto) translation in both Firefox and Chromium.