Content-Language

This article is a stub. You can help the whatwg.org wiki by expanding it.

Open Poll Closes 2010-06-30

Please submit your objections to meta Content-Language in this poll (which closes very soon)

http://www.w3.org/2002/09/wbs/40318/issue-88-objection-poll/

as well as adding them to this wiki page.

Summary

The meta tag, specifically http-equiv Content-Language pragma, is confusing and broken and should be removed from HTML5 altogether.

See related issue: http://www.w3.org/html/wg/tracker/issues/88

remove Content-Language

http://lists.w3.org/Archives/Public/public-html/2010Apr/0308

• This seems like the best option. It is preferable to remove broken features rather than keep them (even if "non-conforming") to minimize risk of continued misuse/misunderstanding and otherwise time-wasting on behalf of web designers and developers. Tantek 01:29, 27 June 2010 (UTC)

keep Content-Language as non-conforming

http://lists.w3.org/Archives/Public/public-html/2010Apr/0307.html

• I'd still prefer complete removal of a broken feature rather than issuing warnings. Tantek 01:29, 27 June 2010 (UTC)

allow multiple language tags in Content-Language

http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages

• Even the "Summary" for this proposal is long and confusing. The workarounds provided in the change proposal increase web authoring complexity. Broken features should be removed, from the language and the specification, rather than asking web developers to waste time learning about broken features and how to work around them. Let's keep the spec as clean as possible. Tantek 01:29, 27 June 2010 (UTC)

Difference Between Content-Language HTTP Header and Pragma Directive

This premise of this change proposal is that the Content-Language HTTP header field is functionally equivalent to the Content-Language pragma directive using the meta element. This premise is used to support the idea that that both should share the same syntax and client side processing requirements. However, this premise is demonstrably wrong, and thus the change proposal is unsupported by evidence and must be rejected.

In order to demonstrate the differences between the HTTP header and the pragma directive, it is necessary to analyse the purpose and functionality of each and see how they compare.

Declaring the Language of the Intended Audience

The HTTP Content-Language header field is used by HTTP servers to announce the language of the intended audience for a given resource representation. This and other related information exchanged between the client and server can be used for content negotiation based on language. When the server does this, it is important for this information to be included in the HTTP header where it can be seen by both the client and other intermediary servers.

The information declared within the document using the pragma directive is unsuitable for this purpose, as it will not be parsed by intermediary servers that would otherwise utilise the information for caching purposes.

Server Configurataion

It has been claimed that the information declared using a pragma directive within the document may be parsed by some server implementations, which subsequently process and echo the value in the Content-Language HTTP header field. Since this header field is allowed to contain multiple language values, it is claimed that this ability is limited by permitting only one language in the pragma directive. However, no evidence has been presented to demonstrate how widely used this feature is, nor why such a feature should even be defined within HTML.

This is a layering violation because information intended for server side processing, and specific implementation details thereof, should not unnecessarily affect the conformance definition of client side HTML. That is, it is out of scope for HTML, as a client side markup language, to define specific processing requirements or features to be used by servers for implementing HTTP features. There is also no inherent need for interoperability between different back end implementation details.

Defining the pragma directive in a way that is optimised for specific server implementation details would be analogous to, for example, defining an ASP specific feature within HTML for use on Microsoft IIS platforms. While server implementations are otherwise free to make any design choices, those design choices need not affect HTML conformance requirements.

Default Document Language

In practice, Content-Language used within the meta element in the HTML serves as client side metadata. The functionality of Content-Language in this case is restricted entirely to the purpose of specifying a fallback language, to be used in the absence of the lang attribute. This purpose differs significantly from the purpose of declaring the languages of the intended audience.

Declaring multiple languages for the document's intended audience makes sense in some cases. However, there can only be one default language. Thus, for this purpose, the functionality as defined requires that only a single language value be specified. While the HTTP Content-Language header field is also used for determining the fallback language in cases where it only has a single language value, that is not its primary purpose and is thus not a significant similarity between these two independent features.

Permitting multiple language values to be specified in the pragma directive is at odds with its implementation requirements. Thus, for the client-side meta data functionality of the pragma directive, it is not at all useful to have multiple languages specified, and so it does not make sense for multiple languages to be considered conforming.

These 3 aspects of the functionality — declaring the langauge of the intended audience, server side configuration and default document language — clearly illustrate that the premise of this change proposal — the shared functionality between the two features — is fundamentally flawed. The reality is that the in-document Content-Language pragma directive only shares its name with the HTTP header field, while its functionality is closer to that of the lang attribute. And since server side implementation details are out of scope of HTML, there is no need for the document conformance definition to permit multiple language values. The solution chosen for addressing this issue must take this into account, and thus reject this change proposal.