This document is an editor's copy. It supports markup to identify changes from a previous version.
Two kinds of changes are highlighted: new, added text, and deleted text.
[ contents ]
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Specifying the language of content is useful for a wide number of applications, from linguistically sensitive searching to applying language-specific display properties. In some cases the potential applications for language information are still waiting for implementations to catch up, whereas in others, such as detection of language by voice browsers, it is a necessity today. Marking up language information is something that can and should be done today. Without it, none of these applications can be taken advantage of.
This document is one of a series of documents providing HTML authors with techniques for developing internationalized HTML using XHTML 1.0 or HTML 4.01, supported by CSS1, CSS2 and some aspects of CSS3. It focuses specifically on advice about specifying the language of content. It is produced by the Internationalization GEO (Guidelines, Education & Outreach) Working Group of the W3C Internationalization Activity.
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Working Draft of a document produced by the Internationalization GEO (Guidelines, Education & Outreach) Working Group, part of the W3C Internationalization Activity. This is a draft document that may not fully represent the consensus of the group at this time. The Working Group expects to advance this Working Draft to Working Group Note
The document provides practical techniques related to specifying the language of content that HTML content authors can use to ensure that their HTML is easily adaptable for an international audience. These are techniques that are best addressed from the start of content development if unnecessary costs and resource issues are to be avoided later on.
A new version of the Working Draft has been published at this time to enable wide review and feedback before moving the document to Working Group Note status.
The Task Force encourages feedback about the content of this document (as well as participation in the development of the techniques by people who have experience creating Web content that conforms to internationalization needs). Send comments about this document to www-i18n-comments@w3.org. The archives for this list are publicly available.
The Internationalization Working Group will not allow early implementation to constrain its ability to make changes to this specification prior to final release. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. At the time of publication, the Working Group believed there were no patent disclosures relevant to this specification.
html
taghtml
declarations for multilingual docslang
or xml:lang
attribute?Content-Language
for text-processingbody
tag rather than the html
tagAll HTML content authors working with XHTML 1.0, HTML 4.01, XHTML 1.1, CSS1, CSS2 and CSS3.
The term 'author' is used in the sense described by the HTML 4.01 specification, ie. as a person or program that writes or generates HTML documents.
This document provides guidance for developers of HTML that enables support for international deployment.
Enabling international deployment is the responsibility of all content authors, not just the localization
groups or vendors, and is relevant from the very start of development. Ignoring the advice in this document,
or relegating it to a later phase in the development process, will only add unnecessary costs and resource issues at a
later date.
It is assumed that readers of this document are proficient in developing HTML and XHTML pages - this document limits itself to providing advice specifically related to internationalization.
This document is one of several documents relating to the design of XHTML and HTML documents.
If you are new to this topic you may wish to read this document from end to end. It is, however, expected
that this document will typically be used for reference purposes - the reader dipping in to a particular section to
find out how to perform a specific task with internationalization in mind. In order to support this kind of usage, an
effort has been made to make each technique self-sufficientstand alone, or to point to relevant
cross-references. In some cases this leads to a small amount of repetitiveness.
Cross-references and additional resources are summarized at the end of each technique.
Editorial notes have been left in this version of the document. [Ed. note: These are marked like this].
Information is also available about the applicability of recommendations to user agents (see belowsee 1.5 User agents addressed support).
An outline document is available that summarizes all the recommendations of this and its companion documents together. The outline is organized according to tasks that a developer of XHTML/HTML content may want to perform. When this material is used as a reference, it is recommended that the overview document is used as a starting point.
This document provides techniques for developing pages using HTML 4.01, XHTML 1.0 and XHTML 1.1 with CSS1, CSS2 and some parts of CSS3.
Note that XHTML 1.0 source can be served as XML (using MIME types
application/xhtml+xml
, application/xml
or text/xml
) or HTML (using the MIME type
text/html
).
It is very common for XHTML 1.0 to be served as HTML, following the
compatibility guidelines in Appendix C of the XHTML
1.0 specification. This allows authors with the right editing tools to produce valid XML code. HTML
represented as valid XML code lends itself to processing with such things as scripting or XSLT, but is also well
supported for display by most mainstream browsers. (XHTML served as application/xhtml+xml
is not well
supported for browser display at the moment.)
In this document we wish to reflect practical reality for content authors, so we cover XHTML served as
text/html
in the techniques. Indeed we encourage the use of XHTML, and all the examples (unless trying to make
a specific point about HTML 4.01) are written in XHTML.
For XHTML served as XML, this document limits its advice to documents served as
application/xhtml+xml
. Note that user agent support for XHTML served as XML is still patchy.
In order to improve the value of this information to the user wWe try to ground
techniques with information about their applicability to particular user agents. User agents, in the current version of
this document, means a number of mainstream browsers. (The scope may grow as resources and test results become
available for other user agents.)
In an attempt to make manageable the task of tracking browser applicabilityWe have chosen a 'base version' for each of the user agents we are tracking. This
base version represents a fairly recent, standards-compliant version of the browser, but nonetheless a version that we
might expect many people to be using. Where a browser operates in both
standards- and quirks-mode,
standards-mode is assumed (ie. you should use a DOCTYPE statement).
manageable, w
The base versions considered for this version of the document include:
Internet Explorer 6 (Windows)
Firefox 1.0
Mozilla 1.4
Opera 7.0
Netscape Navigator 7.0
Safari 1.03
Internet Explorer 5.2 (Mac)
We will also assess the applicability of the techniques against the latest version of the user agent available at the time of publication. This will indicate progress made since the base versions. For this version of this document, that means:
Internet Explorer 6 (Windows)
Firefox 1.0
Mozilla 1.7.2
Opera 7.5.4
Netscape Navigator 7.1
Safari 1.2.2
Internet Explorer 5.2 (Mac)
Generally, the techniques described will be applicable for immediate use. However we may also recommend things that are not yet widely supported, but are described by the standards, and hopefully will be supported given a little time. Where issues of this kind exist, or other issues related to user agent support, these will be flagged by small graphics immediately after the technique summary:
A user agent name followed by indicates that there are no issues with support for this technique.
A name followed by indicates that there were issues surrounding implementation on the base version of the user agent, but not the latest version.
The icon indicates that there continue to be issues.
We will then generally describe the issues in the detailed text that follows.
Summaries for such techniques will also be worded more cautiously. For example, "Consider doing X".
If more testing is needed to ascertain whether there are issues with a particular user agent, the user agent name will be followed by a question mark.
Detailed information may also be provided from time to time about behavior of a user agent in another version than the base or current versions.
Applications exist that can use information about the natural language of content to deliver to users the most relevant information, based on their language preferences. The more content is tagged and tagged correctly, the more useful and pervasive such applications will become.
Language information should be specified for the page as a whole, and wherever language changes within the page.
Applications for language information include authoring tools, translation tools, accessibility, font selection, page rendering, search, and scripting.
There are existing applications that require language information, such as for voice browsers in the accessibility world. There are other areas where language information could still be better exploited. This may change in the future, particularly as the larger search engines take an increasing interest in language. However, we are currently faced with a circular problem. People who don't see the applications of language information do not provide information about their content. Language-related applications are slow to be deployed until this information is widely available. This cycle can be broken by content authors taking steps to declare language information. This is usually very easy to do right now, and carries no penalties.
Primary language is metadata about the document as a whole. Such metadata may be used for searching, serving the right language version, classification, etc. It is not specific enough to indicate the language of a particular run of text in the document for text-processing - for example, in a way that would be needed for the application of text-to-speech, styling, automatic font assignment, etc. It typically describes the language of the intended audience of the document .
The primary language does not describe every language used in a document. Many documents on the Web contain embedded fragments of content in different languages, whereas the page is clearly aimed at speakers of one particular language. For example, a German city-guide for Beijing may contain useful phrases in Chinese, but the primary language of the page is German, ie. it is aimed at a German-speaking audience.
It is also possible to imagine a situation where a document contains the same or parallel content in more than one language. For example, a Web page may welcome Canadian readers with French content in the left column, and the same content in English in the right-hand column. Here the document is equally targeted at speakers of both languages, so there are two primary languages. (This situation is not as common on the Web as in printed material since it is easy to link to separate pages on the Web for different audiences).
There are also pages where the navigational information, including the page title, is in one language but the content of the page is in another. While this is not necessarily good practice, it does not change the fact that the primary language is usually that of the content (the language of the reader of the page) independent of the language at the top of the document source.
Primary language metadata is usually best declared outside the document in the HTTP Content-Language header,
although there may be situations where an internal declaration using the meta
element may be appropriate
(see 6 Specifying primary language metadata).
When specifying the text-processing language you are declaring the language in which a
particularspecific range of text is actually written, so that user agents or applications
that manipulate the text, such as voice browsers, spell checkers, or style processors can effectively handle the text
in question. So we are, by necessity, talking about associating a single language with a specific range of
text.
The text-processing language is usually best declared using attributes on elements. Enclosed elements inherit the declared value, but you can, of course, override an initial declaration by specifying a different language on embedded elements where the language changes, eg. a French word in an English paragraph (see 5 Declaring the text-processing language).
The default text-processing language is not necessarily the same as the primary language of a document.
'Character encoding' refers to the bytes that are used to represent characters in text. It is important to declare what encoding is being used for your document.
In some scripts, such as Arabic and Hebrew, text runs predominantly from right to left. Within that flow, numbers and text from other scripts run from left to right. It is important to adequately specify the intended 'directionality' of text in a document.
Language declarations in HTML and XHTML have nothing to do with character encoding or the direction of text.
Some people think that information about natural language can be inferred from the character
encoding, but this is not true. There must be a one-to-one mapping between encoding and language for this to work, and
there isn't. A single character encoding such as ISO 8859-1 (Latin1), could encode both French and English, as well as
a great many other languages. In addition, different character encodings can be used for a single language, eg, Arabic
could be encoded with 'Windows-1256' or 'ISO 8859-6' or 'UTF-8'.
Similarly, there is not always a one-to-one mapping between language and script, and therefore directionality. For example, Azerbaijani can be written using both right-to-left and left-to-right scripts.
There are separate mechanisms for declaring character encoding and directionality in HTML and XHTML, and
these ideas should not be conflatedconfused with mechanisms for declaring language.
Additional techniques documents at the W3C Internationalization site describe how to declare character encoding and text direction.
There are a number of places defined by the HTML specification where language can be declared.
One method is to use the lang
and xml:lang
attributes on the html tag.
<html lang="en" xml:lang="en" >
Alternatively, you may find documents that provide language information using a meta element.
<meta http-equiv="Content-Language" content="en"/>
Language information may also be found in the HTTP header that is sent with a document (see the last line in the following example of an HTTP header).
HTTP/1.1 200 OK Date: Wed, 05 Nov 2003 10:46:04 GMT Server: Apache/1.3.28 (Unix) PHP/4.2.3 Content-Location: CSS2-REC.en.html Vary: negotiate,accept-language,accept-charset TCN: choice P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml Cache-Control: max-age=21600 Expires: Wed, 05 Nov 2003 16:46:04 GMT Last-Modified: Tue, 12 May 1998 22:18:49 GMT ETag: "3558cac9;36f99e2b" Accept-Ranges: bytes Content-Length: 10734 Connection: close Content-Type: text/html; charset=iso-8859-1 Content-Language: en
It is also worth noting that the meta element and the HTTP header both support a list of values. The example below declares the primary languages of the document to be (in equal measure) German, French and Italian.
<meta http-equiv="Content-Language" content="de, fr, it"/>
It is not possible to declare the language of text in CSS declarations.
This document addresses the question of which approach is the best in what situation.
For a discussion of why it is important to declare language information in a document see the article
Why use the language attribute? and the beginning of the
tutorial
Using Language Information in XHTML, HTML and
CSS.
See also 6 Specifying primary language metadata, which deals with the special case where there are more
than one primary languages.
You should always declare the text-processing language of the page using the lang
and/or xml:lang
attributes. Example 5 declares an HTML document to be in
Canadian French:
<html lang="fr-CA">
For details of which language attribute to use, see a later technique.
For details of how to use language codes, see 7 Choosing language values.
Declaring the text-processing language in the html
tag sets the default text-processing language for the whole document. It can be overridden for portions of the document
as required. This is already important for applications such as
accessibility and searching, but many
other possible applications for this information may
develop over time.
You should always declare the text processing language of the page using the lang
and/or xml:lang
attributes. This is already important for applications such as
accessibility and searching, but many
other possible applications for this information may
develop over time.
Example 5declares an HTML document to be in Canadian
French:
Note that language declarations in the HTTP header or the Content-Language meta
tag should be used
to describe the primary language, ie. metadata about the document as a
whole, rather than the default text-processing language. Most documents have one primary language, but where there are
more it may not be necessary to declare a single default text-processing language in the html
tag. The
relevance will depend on the structure used for the document.
For details of which language attribute to use, and how to use language codes, see
7 Choosing language values.
For a comparison of 'primary language' and 'text-processing language', see 3 Important concepts.
The language attribute on the html
tag should be used to declare the default
text-processing language for the document. Given that only one language
can be defined at a time as the text-processing language, there may appear to be little point in using an attribute on
html
if all primary languages are used in a completely unbiased
way in the document. It may be more appropriate to begin labelling the language on lower level elements.
If, however, the page header information or navigation is in one particular language, or there is a bias of
some other kind towards one particular language, you may want to use a language attribute on the html
tag.
For details of how to specify values for language attributes, see the section 7 Choosing language values.
NOTE: Note that tThere is a definite problem when dealing with multilingual
title
elements. Only one language can be declared for this element in HTML 4.01, since the only content
allowed is character data.
[Ed. note: Should we mention the use of 'mul' as a language code? If we do, should we recommend it or not?]
For details of how to use language attributes, see the section 7 Choosing language values.
Where the language of the text is different from the language declared in the html
tag, you should
indicate this using the lang
or xml:lang
attributes. For example, in HTML you would
write:
<p>The French for <em>Cat</em> is <em lang="fr">chat</em>.</p>
The lang
attribute can be used on all HTML elements except applet
, base
,
basefont
, br
, frame
, frameset
, iframe
, param
and script
.
(Note, by the way, that this means that you could use language attributes on things like bitmaps and audio files that
are language specific. Such information may be particularly useful for script-based processing of documents.)
If there is no markup around the text in a different language, use a span
element to delimit the
boundaries. Here is an example in XHTML 1.0 served as text/html:
<p>The title in Chinese is <span lang="zh-Hans" xml:lang="zh-Hans">中国科学院文献情报中心</span>.</p>
For details of which language attribute to use, see a later technique.
For details of how to use language codes, see 7 Choosing language values.
For details of which language attribute to use, and how to use language codes use, see
7 Choosing language values.
When serving HTML you should use the lang
attribute to declare
the language of the document or a range of text. For example, the following declares a document to be in Canadian
French:
<html lang="fr-CA">
When serving XHTML as text/html, you should use both the lang
attribute and the
xml:lang
attribute. The xml:lang
attribute is the
standard way to identify language information in XML. Example 9 shows how you would
mark up the previous example for XHTML 1.0 served as text/html.
<html lang="fr-CA" xml:lang="fr-CA" >
The xml:lang
attribute is not actually useful for handling the file as HTML, but takes over from
the lang
attribute any time you treat the document as XML for, say, scripting or validation.
If you are serving XHTML 1.0 pages as XML (ie. using a MIME type such as application/xhtml+xml), or serving
pages as XHTML 1.1, you do not need the lang
attribute, since lang
is part of the HTML language. The
xml:lang
attribute alone will suffice (see Example 10).
<html xml:lang="fr-CA" >
Use HTTP headers and meta elements to refer to primary language, and language attributes on the
html
tag to indicate the default text-processing language.
There is generally a lot of confusion about the difference between declaring language information using
Content-Language in HTTP or meta
elements, and using language attributes. In particular, much of the informal
advice on the Web about how to declare the language of a document tells you to use the meta
tag to declare the
language of the document. At least one popular authoring tool automatically inserts into the meta
element
language information that you declare in the page properties dialog box. Unfortunately, we have yet to identify any
user agent or application that recognizes information declared in this way for text-processing, whereas language
information declared in the html
tag is consistently recognized.
Techniques in this document recommend that Content-Language be used for describing primary language metadata, and that attributes be used for describing the default text-processing language of the document. (In fact, this question only arises when describing the language of a document at the highest level, since the language of fragments in a document can only be expressed using attributes.)
It is easy to see the rationale here when dealing with documents with multiple primary languages. The language attribute can only declare a single language at a time. Content-Language declarations, however, can declare a list of languages. Also, Content-Language declarations that declare a list of languages are not specific enough to indicate the default text-processing language.
Furthermore, it is strangely inconsistent not to use attributes to declare the default text-processing language when they have to be used for all fragments of text in a document.
The HTML specification recommends that, in the absence of a language attribute, the HTTP information be used to establish the default text-processing language. (Note that there is no mention of the meta element in the HTML specification.)
In practise, the information contained in HTTP Content-Language headers is rarely used by mainstream
browsers for language-dependent processing, and such implementation as there is is inconsistent. The behaviour of
mainstream browsers also varies when multiple languages are declared in the HTTP header. The information in the
meta
tag is typically not recognized at all by current user agents in a processing context.
There are still some unknowns related to the use of language information due to the currently low level of exploitation of this information. This may change in the future, particularly as the larger search engines take an increasing interest in language. For example, we may in the future see systematic use of in-document declarations of primary language using the meta element. It may also be acceptable to infer primary language from the language attribute on the html element for documents with a single primary language. Discussion amongst various stakeholders needs to take place, however, before this can be known.
In the meantime, we recommend that you use HTTP headers and meta elements to refer to primary language, and language attributes on the html tag to indicate the default text-processing language.
The html
element is the highest level element in the document, and is therefore most appropriate
for declaring the default text-processing language of the document. All
elements within the document will inherit that value.
The body
tag is usually the wrong place to express this information because it only refers to a
portion of the text in the document. For example, the text in the title
element is natural language text that
should also inherit the language information. If language is declared in the body
element, however, this is
not the case.
The only time it would make sense is when the content of the head and body elements are in different languages.
You may come across a situation where the language of the text in an attribute and the element content are in different languages. For example, the top right corner of pages on the W3C Internationalization site show links to translated alternatives (see Figure 1). The name of the language is given in the language of the target page, but a title attribute contains the name in the language of the current page:
If you create the code as shown in Example 11 below, the language
attributes would actually be saying that not only the content but also the title
attribute text is in Swedish.
This is obviously incorrect.
<p>> <a xml:lang="sv" lang="sv" title="Swedish"
href="index.sv.html">svenska</a></p>
A better approach would involve moving the title attribute up a level in the hierarchy, since in this
example the p
tag inherits the default en
setting of the html
tag.
<p title="Swedish">> <a xml:lang="sv" lang="sv"
href="index.sv.html">svenska</a></p>
The markup in Example 12 lends itself easily to this approach. In other
cases you may need to add a span
element.
The Content-Language declaration, whether it is used in the HTTP header or a meta tag, can be useful
for expressing metadata about the primary language(s) of the document
being served.
Content-Language information sent in the HTTP header is defined on the server.
Example 13 shows how the language would be declared in a meta tag inside a document:
<meta http-equiv="Content-Language" content="en"/>
The Content-Language declaration, whether it is used in the HTTP header or a meta tag, can be useful for expressing metadata about the primary language(s) of the document being served.
Note that this is different from expressing the default language of content for
text-processing, which must be done using a language attribute on the
html
tag.
The extent to which applications use metadata information in the HTTP header or a meta tag, or which of the two is preferred, is not clear at this point.
Using the HTTP Content-Language header entails potential issues related to the maintenance and use of server-side information. Many authors may find it difficult to access server settings, particularly when dealing with an ISP. Also, pages may not always be located on servers. So this approach is not a solution that is always available.
For a comparison of 'primary language' and 'text-processing language', see the section 3 Important concepts.
It is not common to find pages on the Web with more than one primary language. One reason is that it is easy to link to alternative pages instead. Furthermore, there may be differing views on what kind of document structure reflects a document with multiple primary languages.
For a discussion of why it is important to declare the language of a document see the article
Why use the language attribute? and the beginning of the
tutorial
Using Language Information in XHTML, HTML and
CSS.
See the previous section for techniques related to the general case, ie. a single
primary language.
The HTTP specification provides for more than one language to be expressed as the value of the Content-Language header.
Example 14 shows part of the HTTP header sent from the server and declares a document to have three primary languages: German, French and Italian:
Content-Language: de,fr,it
The in-document meta
element provides a similar possibility (see Example
15):
<meta http-equiv="Content-Language" content="de,fr,it"/>
Dividing parallel text at the highest possible level, can simplify the process of guiding users to the text via searching, links, etc. It also reduces the work of labeling the language of document fragments.
For details of how to use language attributes, see the section 7 Choosing language values.
RFC 3066 is the IETF document that defines how to use language tags to identify languages. It obsoletes the RFC 1766 referred to by earlier specifications.
For an introduction to the RFC3066 rules for language codes, see Specifying language attribute values in the tutorial Using Language Information in XHTML, HTML and CSS.[Ed. note: I think we should create a separate article/faq containing this information, since the tutorial is subject to change (especially the titles of sections). A document that provided this information, dedicated to addressing this point for this techniques document, would be a much safer bet.]
RFC 3066 merely expands and clarifies the possibilities for specifying languages. If you have been using RFC 1766 you typically do not need to make any changes to your code in order to start using RFC 3066.
NOTE: The HTML specification still recommends the use of RFC 1766 for identifying language. There is a planned erratum in place for the HTML specification, so you should use RFC 3066 despite what the HTML specification currently says.
A proposed successor to RFC 3066 is currently being developed, but it aims to retain backwards compatibility with tags created using RFC 3066.
Note also that lang
and xml:lang
attributes only take a single language value (unlike HTTP
Content-language headers).
For an introduction to the RFC3066 rules for language codes, see
Specifying language attribute
values in the tutorial Using Language Information in XHTML, HTML and
CSS.
RFC3066 specifies that the two letter codes should be used where available, since this aids interoperability by ensuring that a single code is used everywhere to refer to a particular language.
This also avoids the question of which 3-letter code to use for those languages that have two 3-letter codes, since all such languages have a 2-letter code also.
Now the IANA registry makes available the codes zh-Hans
and zh-Hant
for Simplified
and Traditional Chinese, respectively. The following two examples illustrate the use of these tags.
Simplified Chinese:
<p lang="zh-Hans" xml:lang="zh-Hans">当世界需要沟通时,请用统一码!</p>
Traditional Chinese:
<p lang="zh-Hant" xml:lang="zh-Hant">當世界需要溝通時,請用統一碼!</p>
RFC3066 specifies how to identify a language. Simplified vs. Traditional Chinese is a
distinction based on script. In the past zh-CN
(Chinese spoken in Mainland China) was
commonly used to label Simplified Chinese, and zh-TW
(Chinese spoken in Taiwan) was commonly used for
Traditional Chinese. Apart from the fact that this is mislabeled, you could not guarantee that others would recognize
these conventions, or even follow them. For example, some people used zh-HK to represent Traditional Chinese.
Now the IANA registry makes available the codes zh-Hans
and zh-Hant
for Simplified
and Traditional Chinese, respectively. The following two examples illustrate the use of these tags.
It is expected that these tags will persist for the foreseeable future, so on the one hand it would be good to use them as soon as possible in order to improve interoperability sooner rather than later.
On the other hand, you need to assess the impact of changing the tags. This is not really an issue for
self-describing usage, such as with :lang
for application of language-based styling. It may be more of an
issue where external applications are looking for tags related to Chinese but are unaware of the zh-Hans and zh-Hant
variants.
NOTE: There is one particular area where this may be an issue for the display of text on a user agent. Some (but not all) user agents use language information to automatically choose a font for CJK ideographic text. Note that this assumes that (a) you have appropriate fonts set in your preferences, that (b) the document styling does not apply a font, and that (c) the user agent supports this behavior (not all do). The following table summarizes support for this feature in various user agents (see the test results page for more details):
IE 6.0 (Win) | Does not recognize either of these codes. |
Firefox 1.0 | Handles both codes correctly. |
Mozilla 1.7.2 | Recognizes the tags but treats them both as Simplified Chinese. |
Netscape 7.0 | Recognizes the tags but treats them both as Simplified Chinese. |
Opera 7.54 | Doesn't automatically apply fonts in this fashion, so is irrelevant. |
IE 5.2 (Mac) | Recognizes the tags but treats them both as Traditional Chinese. |
Safari | [Ed. note: Add this !] |
If you add some text or graphic to a link indicating that the target document is in another language, it may allow the reader to decide in advance whether or not to follow the link, according to their language skill. If the user has to waste time following the link to find out that they cannot read the target document, this introduces fatigue, and they may lack confidence when faced with links that do go to readable pages.
There are, however, potential problems with this approach.
For example, a newly translated version may become available. Assume, for example that a French page has used this approach some time ago to point to a document which at that time was only in English. Later, the document is translated into French and language negotiation is put in place. Unless the French page referred to earlier is updated, it will now be incorrectly warning French readers that the document is in English, and possibly discouraging them from following a link to what is actually a perfectly legible document.
In HTML, the hreflang attribute on an a
element indicates the language of the document at the other
end of the link. In practice, hreflang
is typically not used by mainstream browsers. Besides that it is much
better to ensure that the target document uses the language attribute in the html
tag, so that this
information is not needed.
A common alternative use for this attribute is to generate a visible marker attached to link text that indicates the language of the destination page for the reader. The idea is to allow the reader to decide in advance whether or not to follow the link, according to their language skill.
This approach relies on CSS selectors that detect the value of the hreflang
attribute and use the
CSS content property to display an indicator of the language.
For example, the following link points to a page in Swedish.
There is also a translated page describing why a DOCTYPE is useful [sv].
The code to enable this in CSS may be something like:
a[hreflang]:after { content: " [" attr(hreflang) "] "; }
This says, "For each a
element with an hreflang
attribute, add the value of that attribute
in square parentheses after the link". You could just as easily append text or even a graphic after the link.
The markup would read as follows:
<p>There is also a translated page describing <a href="swedish-doc.html" hreflang="sv">why a DOCTYPE is useful</a>.</p>
There are some usability-related pros and cons to this approach that are discussed in the previous technique.
There are, howeveralso, potential technical problems with this approach.
Firstly, not all user agents support the CSS required to enable it (see the
test results page). Internet Explorer does not
support :after
.
AlsoSecondly, note that if a resource is available in multiple languages (say you are
linking from an English overview to detailed descriptions that are available in multiple languages) it is not possible
to express that, since the hreflang
attribute accepts only a single language as its value.
Flags represent countries, not languages. There are many countries that use the same language, and numerous countries that have more than one official language.
A much better approach is to use text. In the previous technique, an example is shown that uses the actual attribute value, since these two-letter codes are typically recognizable by speakers of the language.
The following members of the GEO Working Group and the former GEO Task Force have contributed their time and valuable comments to shaping these guidelines:
Phil Arko (Siemens), Steve Billings, Deborah Cawkwell (BBC World Service), Wendy Chisholm (W3C WAI), Andrew Cunningham (State Library of Victoria), Martin Dürst (W3C), Lloyd Honomichl, Susan K. Miller (Boeing), Russ Rolfe (Microsoft), Peter Sigrist, Tex Texin (XenCraft), Najib Tounsi (Ecole Mohammadia d'Ingénieurs)