ISSUE-23: [Bug 12278] [polyglot] i18n: Make lang and xml:lang required on the root element

[Bug 12278] [polyglot] i18n: Make lang and xml:lang required on the root element

Raised by:
Richard Ishida
Opened on:

Summary: [polyglot] i18n: Make lang and xml:lang required on
the root element.
Product: HTML WG
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: HTML/XHTML Compatibility Authoring Guide (ed: Eliot

XML and HTML differ w.r.t. whether the HTTP Content-Language: header MUST or
MAY change the language of an element from 'unset' to a specific language. And
for http-equiv="Content-Language", then HTML has clear rules, whereas XML is
silent. These differences can cause the language to be set on the HTML side,
while it remains unset on the XML side.

EITHER require authors to create polyglot markup that is immune against the
possibility that the Content-Language value (from either http-equiv pragma or
HTTP header) can change the language from 'unset' to some specific language in
an assymmetric way (that is: only on the HTML side): Basically, make
@xml:lang/lang required on the root element - at least in some situations.
OR accept the differences and document, in the Polyglot Markup
specification, how XML and HTML differ.

A) http-equiv="Content-Language"

HTML5 - MUST be used in absence of @lang:

]] If none of the node's ancestors, including the root element,
have either attribute set, but there is a pragma-set default
language set, then that is the language of the node. [[

XML 1.0 - is silent w.r.t. http-equiv.
However, some common XHTML user agents DO use
http-equiv="content-language". While others don't.
If considered as equal to http ... then it is
correct to respect it. HTML5 do not consider it equal.
Does it, in XML, depend on a DTD?

B) HTML5 - higher protocols MUST be used as backup:

]] If there is no pragma-set default language set, then language
information from a higher-level protocol (such as HTTP), if
any, must be used as the final fallback language instead. [[

XML 1.0 - external transport protocol MAY be used as backup
(we must ASSUME that 'Content-Language' is what is meant):

]] Language information may also be provided by external
transport protocols (e.g. HTTP or MIME). When available, this
information may be used by XML applications, but the more
local information provided by xml:lang should be considered
to override it. [[

C) MULTIPLE Content-Language VALUES

HTML5 specs that Content-Language (http or http-equiv) only
affects the language when its value is a single language tag.
There is no general clarafication of this when it comes to XML.


(1) Conditional: REQUIRE @xml:lang/@lang on root when there is a
Content-Language (http-equiv pragma or HTTP header) whose value is exactly a
single language tag.
PRO: Polyglot Markup would follow the same rules as HTML5, except with
a stricter conformance requirement.
CON: Complexity. Such a rule is a complex for authors to administrate.
For example, it would mean that if the HTTP server sends out a single
Content-Language header without the author's awareness, then the document is
assigned a language - which in turn only HTML user agents would be REQUIRED to
ISSUE-88: My Change Proposal for ISSUE-88 suggest that validators will
pick up the HTTP Conent-Language header and warn whenever it causes the
language to be set.

(2) Always REQUIRE @xml:lang/@lang on the root element.
PRO: Simple rule.
CON: Less flexibillity. The fact that the language can be inherited
from the higher protocol can also be an advantage. And also, for XML, if one
combines several documents into a bigger one (for example by the use of
XINCLUDE), then each <html> element of the new, combined document, might end up
with the language explicitly defined. (In contrast, if the root element
language was unset, then the <html> elements would inherit the language from
the parent element in the new document.)
CON: PERHAPS it could increase the tendency to use bogus language
declarations. (Many templates comes with "en" as the default.)
CON: PERHAPS it could increase the use of the empty string
declaration, which is equal to explicitly declaring the language as unknown.
<html xml:lang="" lang="" xmlns="*">. Is that bad? If so, why? And when?

(3) Accept and document the differences: In absence of element level
language declaration, then XML apps MAY and HTML uas MUST make use of
Content-Language for setting the language. However, many (or most?) popular Web
browsers that are also capable of handling XHTML *DO* seem to pick up the
language from Content-Language too (from HTTP header and from http-equiv
PRO: Could triger vendors to align XHTML user agents with HTML5
CON: left out in the cold would be specialized non-Web parsers, such
as XSLT, and other parsers that respect the MAY in the XML spec.

(4) Forbidding HTTP Content-Language headers for polyglot markup: NOT A

(5) Forbidding http-equiv=Content-Language in polyglot markup: Possible.
But only limits the problem. Doesn't remove it. Thus one must still choose
between option (1), (2) or (3).

PREFERENCE: My preference is option (2) because it is simplest and because
it seems safest.

In short, yes. But ISSUE-88 is only about what syntax that is permitted
inside http-equiv. It is not about how HTML user agents should *react* to
Content-Language, whether coming from http-equiv or http.
Related Actions Items:
No related actions
Related emails:
  1. Review of tracker issues for best practices (from on 2015-03-25)
  2. I18N-ISSUE-23: [Bug 12278] [polyglot] i18n: Make lang and xml:lang required on the root element [HTML5-mail] (from on 2011-03-23)

Related notes:

No additional notes.

Display change log ATOM feed

Addison Phillips <>, Chair, Richard Ishida <>, Fuqiao Xue <>, Atsushi Shimono <>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: index.php,v 1.326 2018/10/13 17:29:51 vivien Exp $