Internationalization Best Practices for Spec Developers

W3C Group Draft Note

More details about this document
This version:
https://www.w3.org/TR/2022/DNOTE-international-specs-20220501/
Latest published version:
https://www.w3.org/TR/international-specs/
Latest editor's draft:
https://w3c.github.io/bp-i18n-specdev/
History:
https://www.w3.org/standards/history/international-specs
Commit history
Editors:
Richard Ishida (W3C)
Addison Phillips (Amazon)
Feedback:
GitHub w3c/bp-i18n-specdev (pull requests, new issue, open issues)

Abstract

This document provides a checklist of internationalization-related considerations when developing a specification. Most checklist items point to detailed supporting information in other documents. Where such information does not yet exist, it can be given a temporary home in this document. The information in this document will change regularly as new content is added and existing content is modified in the light of experience and discussion.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document provides advice to specification developers about how to incorporate requirements for international use. What is currently available here is expected to be useful immediately, but is still an early draft and the document is in flux, and will grow over time as knowledge applied in reviews and discussions can be crystallized into guidelines.

This document was published by the Internationalization Working Group as a Group Draft Note using the Note track.

Group Draft Notes are not endorsed by W3C nor its Members.

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.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 2 November 2021 W3C Process Document.

1. Introduction

Developers of specifications need advice to ensure that what they produce will work for communities around the globe.

The Internationalization (i18n) WG tries to assist working groups by reviewing specifications and engaging in discussion. Often, however, such interventions come later in the process than would be ideal, or mean that the i18n WG has to repeat the same information for each working group it interacts with.

It would be better if specification developers could access a checklist of best practices, which points to explanations, examples and rationales where developers need it. Developers would then be able to build this knowledge into their work from the earliest stages, and could thereby reduce rework needed when the i18n WG reviews their specification.

This document contains the beginnings of a checklist, and points to locations where you can find explanations, examples and rationales for recommendations made.  If there is no such other place, that extra information will be added to this document. It may also be used to develop ideas and organize them.

The guidelines in this document are not intended to be hard and fast requirements. This document will achieve a significant part of its purpose if, where you don't understand the guidelines or disagree with them, you contact the Internationalization WG to discuss what should be done.

Note

In this document, the term natural language is usually used to refer to the portions of a document or protocol intended for human consumption. The term localizable text is used to refer to the natural language content of formal languages, protocol syntaxes and the like, as distinct from syntactic content or user-supplied values. See the [I18N-GLOSSARY] for definitions of these and other terms used by the Internationalization Working Group.

1.1 Create a github checklist

To do a self-review, you can create a checklist from this page, and paste it into a wiki page in your GitHub repository. Checkboxes alongside an item can be used to indicate whether or not the recommendation is applicable to your spec. You can add notes/questions to each item by editing the wiki. This will alert the Internationalization Working Group to your review.

To create the text, simply click on the button just below, then paste the output it generates into a new wiki in your repository. We recommend that you then create a GitHub issue that points to the wiki page, and add the i18n-tracker label to it.

We suggest that, before creating this source dump, you open the checklists just after each level 2 heading in this document and add a check mark alongside the items that are relevant to your spec. These will then be marked in your wiki.

2. Language

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Language basics
  • It should be possible to associate a language with any piece of localizable text or natural language content. more
  • Where possible, there should be a way to label natural language changes in inline text. more
  • Consider whether it is useful to express the intended linguistic audience of a resource, in addition to specifying the language used for text processing. more
  • A language declaration that indicates the text-processing language for a range of text must associate a single language value with a specific range of text. more
  • Use the HTML lang and XML xml:lang language attributes where appropriate to identify the text processing language, rather than creating a new attribute or mechanism. more
  • It should be possible to associate a metadata-type language declaration (which indicates the intended use of the resource rather than the language of a specific range of text) with multiple language values. more
  • Attributes that express the language of external resources should not use the HTML lang and XML xml:lang language attributes, but should use a different attribute when they represent metadata (which indicates the intended use of the resource rather than the language of a specific range of text). more
Defining language values
  • Values for language declarations must use BCP 47. more
  • Refer to BCP 47, not to RFC 5646. more
  • Be specific about what level of conformance you expect for language tags: BCP 47 defines two levels of conformance, "valid" and "well-formed". more
  • Specifications may require implementations to check if language tags are "valid", but in most circumstances should only require that the language tags be "well-formed". more
  • Specifications should require content and content authors to use "valid" language tags. more
  • Reference BCP47 for language tag matching. more
Declaring language at the resource level
  • The specification should indicate how to define the default text-processing language for the resource as a whole. more
  • Content within the resource should inherit the language of the text-processing declared at the resource level, unless it is specifically overridden. more
  • Consider whether it is necessary to have separate declarations to indicate the text-processing language versus metadata about the expected use of the resource. more
  • If there is only one language declaration for a resource, and it has more than one language tag as a value, it must be possible to identify the default text-processing language for the resource. more
Establishing the language of a content block
  • By default, blocks of content should inherit any text-processing language set for the resource as a whole. more
  • It should be possible to indicate a change in language for blocks of content where the language changes. more
Establishing the language of inline runs
  • It should be possible to indicate language for spans of inline text where the language changes. more

2.1 Language basics

§

It should be possible to associate a language with any piece of localizable text or natural language content.

§

Where possible, there should be a way to label natural language changes in inline text.

Text is rendered or processed differently according to the language it is in. For example, screen readers need to be prompted when a language changes, and spell checkers should be language-sensitive. When rendering text a knowledge of language is need in order to apply correct fonts, hyphenation, line-breaking, upper/lower case changes, and other features.

For example, ideographic characters such as 雪, 刃, 直, 令, 垔 have slight but important differences when used with Japanese vs Chinese fonts, and it's important not to apply a Chinese font to the Japanese text, and vice versa when it is presented to a user.

§

Consider whether it is useful to express the intended linguistic audience of a resource, in addition to specifying the language used for text processing.

Language information for a given resource can be used with two main objectives in mind: for text-processing, or as a statement of the intended use of the resource. We will explain the difference below.

2.1.1 Text-processing language information

§

A language declaration that indicates the text-processing language for a range of text must associate a single language value with a specific range of text.

When specifying the text-processing language you are declaring the language in which a specific range of text is actually written, so that user agents or applications that manipulate the text, such as voice browsers, spell checkers, style processors, hyphenators, etc., can apply the appropriate rules to the text in question. So we are, by necessity, talking about associating a single language with a specific range of text.

It is normal to express a text-processing language as the default language, for processing the resource as a whole, but it may also be necessary to indicate where the language changes within the resource.

§

Use the HTML lang and XML xml:lang language attributes where appropriate to identify the text processing language, rather than creating a new attribute or mechanism.

To identify the text-processing language for a range of text, HTML provides the lang attribute, while XML provides xml:lang which can be used in all XML formats. It's useful to continue using those attributes for relevant markup formats, since authors recognize them, as do HTML and XML processors.

2.1.2 Language metadata about the resource as a whole

It may also be useful to describe the language of a resource as a whole. This type of language declaration typically indicates the intended use of the resource. For example, such metadata may be used for searching, serving the right language version, classification, etc.

This type of language declaration differs from that of the text-processing declaration in that (a) the value for such declarations may be more than one language subtag, and (b) the language value declared doesn't indicate which bits of a multilingual resource are in which language.

§

It should be possible to associate a metadata-type language declaration (which indicates the intended use of the resource rather than the language of a specific range of text) with multiple language values.

The language(s) describing the intended use of a resource do not necessarily include every language used in a document. For example, 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 it is aimed at a German-speaking audience, not a Chinese one.

On the other hand, 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 audience languages. Another use case is a blog or a news page aimed at a multilingual community, where some articles on a page are in one language and some in another. In this case, it may make sense to list more than one language tag as the value of the language declaration.

§

Attributes that express the language of external resources should not use the HTML lang and XML xml:lang language attributes, but should use a different attribute when they represent metadata (which indicates the intended use of the resource rather than the language of a specific range of text).

Using a different attribute to indicate the language of an external resource allows the attribute to specify more than one language. It also works better if the resource pointed to is not in a single language.

This distinction can be seen in HTML in the separation of the lang and hreflang attributes. The former indicates the language of the text within the HTML page; the latter is metadata indicating the expected language of a page that is linked to.

For a longer discussion of this see xml:lang in XML document schemas. This article talks specifically about xml:lang, but the concepts are applicable to other situations.

2.2 Defining language values

§

Values for language declarations must use BCP 47.

BCP 47 defines a method to combine subtags in order to create a much more powerful notation for language tags than that provided by the old ISO lists, but it is also backwards compatible with the ISO lists.

For an overview of the key features of BCP 47, see Language tags in HTML and XML.

§

Refer to BCP 47, not to RFC 5646.

The link to and name of BCP 47 was created specifically so that there is an unchanging reference to the definition of Tags for the Identification of Languages. RFCs 1766, 3066, 4646 were previous (superseded) versions and 5646 is the current version of BCP 47.

§

Be specific about what level of conformance you expect for language tags: BCP 47 defines two levels of conformance, "valid" and "well-formed".

A well-formed BCP 47 language tag follows the syntax defined for a language tag: implementations check that each language tag consists of hyphen-separated subtags; each subtag has a specific length and specific content (letters, digits or specific combinations) depending on the placement in the tag. A valid BCP 47 language tag is well-formed but additionally ensures that only subtags that are listed in the IANA Subtag Registry are used. Note that the IANA Subtag Registry is frequently updated with new subtags.

§

Specifications may require implementations to check if language tags are "valid", but in most circumstances should only require that the language tags be "well-formed".

Most specifications are second-order consumers of language metadata – they are using data already provided in the document format (HTML lang, XML xml:lang, or the document format's language fields/attributes).

Generally most specifications are concerned with selecting resources (such as spell checkers, tokenizers, fonts, etc.) or with matching (selecting which string to show, for example) and don't directly care about the content of the language tag. Invalid-but-well-formed tags just don't match anything and usually fallback schemes provide some behavior that is appropriate.

There might be cases where a specification really wants implementation-level checking for validity. In those cases, the result of a tag failing to be valid has to be specified (should the application die, warn the user, etc.). It's also a problem that the registry is sizeable and changes over time, so each implementation is registry-version dependent. The changes over time are often minor, but real users will encounter interoperability issues if random (out of date) implementations of the specification reject language tags that have become valid at a later date.

In addition, BCP 47 has an extension mechanism which defines add-on subtag sequences. For example, one extension [RFC6067] (Unicode Locales, which uses the singleton -u), is commonly used for controlling the internationalization features of JavaScript (and has other uses). Validating these additional subtags is likely out of scope for most specifications.

§

Specifications should require content and content authors to use "valid" language tags.

Normative language regarding language tags might be different between content and implementation requirements. Specification authors need to carefully consider what conformance requirements and tests are needed for their specification and what implementations are required to do. One solution is to normatively require that "valid" language tags be used by content authors but only require implementations to check for "well-formed" language tags.

§

Reference BCP47 for language tag matching.

BCP 47 contains one RFC dedicated to the syntax and subtags of language tags, and another dedicated to how to match two or more subtags. (This topic needs more detail, and may merit being a separate section.)

2.3 Declaring language at the resource level

Here we are talking about an independent unit of data that contains structured text. Examples may include a whole HTML page, an XML document, a JSON file, a WebVTT script, an annotation, etc.

§

The specification should indicate how to define the default text-processing language for the resource as a whole.

It often saves trouble to identify the language, or at least the default language, of the resource as a whole in one place. For example, in an HTML file, this is done by setting the lang attribute on the html element.

§

Content within the resource should inherit the language of the text-processing declared at the resource level, unless it is specifically overridden.

§

Consider whether it is necessary to have separate declarations to indicate the text-processing language versus metadata about the expected use of the resource.

In many cases a resource contains text in only one language, and in many more cases the language declared as the default language for text-processing is the same as the language that describes the metadata about the resource as a whole. In such cases it makes sense to have a single declaration.

It becomes problematic, however, to use a single declaration when it refers to more than one language unless there is a way to determine which one language should be used as the text-processing default.

§

If there is only one language declaration for a resource, and it has more than one language tag as a value, it must be possible to identify the default text-processing language for the resource.

2.4 Establishing the language of a content block

The words block and/or chunk are used here to refer to a structural component within the resource as a whole that groups content together and separates it from adjacent content. Boundaries between one block and another are equivalent to paragraph or section boundaries in text, or discrete data items inside a file.

For example, this could refer to a block or paragraph in XML or HTML, an object declaration in JSON, a cue in WebVTT, a line in a CSV file, etc. Contrast this with inline content, which describes a range within a paragraph, sentence, etc.

The interpretation of which structures defined in a spec are relevant to these requirements may require a little consideration, and will depend on the format of the data involved.

§

By default, blocks of content should inherit any text-processing language set for the resource as a whole.

See 2.1 Language basics for guidance related to the default text-processing language information.

§

It should be possible to indicate a change in language for blocks of content where the language changes.

2.5 Establishing the language of inline runs

In this section we refer to information that needs to be provided for a range of characters in the middle of a paragraph or string.

§

It should be possible to indicate language for spans of inline text where the language changes.

Where a switch in language can affect operations on the content, such as spell-checking, rendering, styling, voice production, translation, information retrieval, and so forth, it is necessary to indicate the range of text affected and identify the language of that content.

3. Text direction

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Basic requirements
  • It must be possible to indicate base direction for each individual paragraph-level item of natural language text that will be read by someone. more
  • It must be possible to indicate base direction changes for embedded runs of inline bidirectional text for all localizable text. more
  • Annotating right-to-left text must require the minimum amount of effort for people who work natively with right-to-left scripts. more
Background information
  • Do not assume that direction can be determined from language information. more
Base direction values
  • Values for the default base direction should include left-to-right, right-to-left, and auto. more
Handling direction in markup
  • The spec should indicate how to define a default base direction for the resource as a whole, ie. set the overall base direction. more
  • The default base direction, in the absence of other information, should be LTR. more
  • The content author must be able to indicate parts of the text where the base direction changes. At the block level, this should be achieved using attributes or metadata, and should not rely on Unicode control characters. more
  • It must be possible to also set the direction for content fragments to auto. This means that the base direction will be determined by examining the content itself. more
  • If the overall base direction is set to auto for plain text, the direction of content paragraphs should be determined on a paragraph by paragraph basis. more
  • To indicate the sides of a block of text relative to the start and end of its contained lines, use 'block-start' and 'block-end', rather than 'top' and 'bottom'. more
  • To indicate the start/end of a line you should use 'start' and 'end', or 'inline-start' and 'inline-end', rather than 'left' and 'right'. more
  • Provide dedicated attributes for control of base direction and bidirectional overrides; do not rely on the user applying style properties to arbitrary markup to achieve bidi control. more
Handling base direction for strings
  • Provide metadata constructs that can be used to indicate the base direction of any natural language string. more
  • Specify that consumers of strings should use heuristics, preferably based on the Unicode Standard first-strong algorithm, to detect the base direction of a string except where metadata is provided. more
  • Where possible, define a field to indicate the default direction for all strings in a given resource or document. more
  • Do NOT assume that a creating a document-level default without the ability to change direction for any string is sufficient. more
  • If metadata is not available due to legacy implementations and cannot otherwise be provided, specifications MAY allow a base direction to be interpolated from available language metadata. more
  • Specifications MUST NOT require the production or use of paired bidi controls. more
Setting base direction for inline or substring text
  • It must be possible to indicate spans of inline text where the base direction changes. If markup is available, this is the preferred method. Otherwise your specification must require that Unicode control characters are recognized by the receiving application, and correctly implemented. more
  • It must be possible to also set the direction for a span to auto. This means that the base direction will be determined by examining the content itself. A typical approach here would be to set the direction based on the first strong directional character outside of any markup. more
  • If users use Unicode bidirectional control characters, the isolating RLI/LRI/FSI with PDI characters must be supported by the application and recommended (rather than RLE/LRE with PDF) by the spec. more
  • Use of RLM/LRM should be appropriate, and expectations of what those controls can and cannot do should be clear in the spec. more
  • For markup, provide dedicated attributes for control of base direction and bidirectional overrides; do not rely on the user applying style properties to arbitrary markup to achieve bidi control. more
  • For markup, allow bidi attributes on all inline elements in markup that contain text. more
  • For markup, provide attributes that allow the user to (a) create an embedded base direction or (b) override the bidirectional algorithm altogether; the attribute should allow the user to set the direction to LTR or RTL or the aforementioned Auto in either of these two scenarios. more

It is important to establish direction for text written or mixed with right-to-left scripts. Characters in these scripts are stored in memory in the order they are typed and pronounced – called the logical order. The Unicode Bidirectional Algorithm (UBA) provides a lot of support for automatically rendering a sequence of characters stored in logical order so that they are visually ordered as expected. Unfortunately, the UBA alone is not sufficient to correctly render bidirectional text, and additional information has to be provided about the default directional context to apply for a given sequence of characters.

3.1 Basic requirements

The basic requirements are as follows.

§

It must be possible to indicate base direction for each individual paragraph-level item of natural language text that will be read by someone.

§

It must be possible to indicate base direction changes for embedded runs of inline bidirectional text for all localizable text.

§

Annotating right-to-left text must require the minimum amount of effort for people who work natively with right-to-left scripts.

Requiring a speaker of Arabic, Divehi, Hebrew, Persian, Urdu, etc. to add markup or control characters to every paragraph or small data item they write is far too much to be manageable. Typically, the format should establish a default direction and require the user to intervene only when exceptions have to be dealt with.

3.2 Background information

In this section we try to set out some key concepts associated with text direction, so that it will be easier to understand the recommendations that follow.

3.2.1 Important definitions

In order to correctly display text written in a 'right-to-left' script or left-to-right text containing bidirectional elements, it is important to establish the base direction that will be used to dictate the order in which elements of the text will be displayed.

If you are not familiar with what the Unicode Bidirectional Algorithm (UBA) does and doesn't do, and why the base direction is so important, read Unicode Bidirectional Algorithm basics.

In this section, the word paragraph indicates a run of text followed by a hard line-break in plain text, but may signify different things in other situations. In CSV it equates to 'cell', so a single line of comma-separated items is actually a set of comma-separated paragraphs.  In HTML it equates to the lowest level of block element, which is often a p element, but may be things such as div, li, etc., if they only contain text and/or inline elements. In JSON, it often equates to a quoted string value, but if a string value uses markup then paragraphs are associated with block elements, and if the string value is multiple lines of plain text then each line is a paragraph.

The term metadata is used here to mean information which could be an annotation or property associated with the data, or could be markup in scenarios that allow that, or could be a higher-level protocol, etc.

3.2.2 Ways base direction can be set for paragraphs

There are a number of possible ways of setting the base direction.

  1. The base direction of a paragraph may be set by an application or a user applying metadata to the paragraph. Typical values for base direction may include ltr, rtl or auto.
    • The metadata may specifically indicate that heuristics should be used. Then you would expect to consider the actual characters used in order to determine the base direction. (This is what happens if you set dir=auto on an HTML element.)
    • The application may expect metadata, but there may be no such information provided. In this case you would usually expect there to be a default direction specified, and the base direction for a cell would be set to that default. The default is usually LTR. (This is what happens if you have no dir attributes in your HTML file.)
    • Where a format contains many paragraphs or chunks of information, and the language of text in all those chunks is the same, it is sometimes useful to allow a default base direction to be set for and inherited by all. This is what happens when you set the dir attribute on the html tag in HTML. Another example would be a subtitling file containing many cues, all written in Arabic; it would be best to allow the author to say at the start of the file that the default is RTL for all cue text. There should always be a way to override the direction information for a specific paragraph where needed.
  2. If the application expects no metadata to be available it should use heuristics to determine the base direction for each paragraph/cell. A typical solution, and one described by UAX 9 Unicode Bidirectional Algorithm, is to look for the first-strong character in the paragraph/cell. (This is likely to apply if you are looking at plain text that is not expected to be associated with metadata. It only happens with HTML if the direction is set to auto, since HTML specifies a default direction.)
    • Not all paragraphs using the first-strong method will have the correct base direction applied. In some cases, an Arabic or Hebrew, etc, paragraph may start with strong LTR characters. There must be a way to deal with this.
    • Where a syntactic unit contains multiple lines of plain text (for example, a multiline cue text in a subtitling file), the first-strong heuristic needs to be applied to each line separately.
    • There may be special rules that involve ignoring some sequence of characters or type of markup at the start of the paragraph before identifying the first strong character.
    • In some cases there are no strong characters in a paragraph, and the base direction can be critically important for the data to be understood correctly, eg. telephone numbers or MAC addresses. There needs to be a way to resort to an appropriate default for these cases.
  3. Whether or not any metadata is specified, if a paragraph contains a string that starts with one of the Unicode bidi control characters RLI, LRI, FSI, LRE, RLE, LRO, or RLO and ends with PDF/PDI, these characters will determine the base direction for the contained string. These characters, when placed in the content, explicitly override any previously set direction by creating an inline range and assigning a base direction to it.
    • The effect of such characters does not extend past paragraph boundaries, but the range ought to be explicitly ended using the PDF/PDI control character, especially if a paragraph end is not easily detectable by the application.)
    • Because isolation is needed for bidirectional text to work properly, the Unicode Standard says that the isolating control codes RLI, LRI and FSI should be used rather than LRE or RLE. Unfortunately, those characters are still not widely supported.
    • For structural components in markup, above the paragraph level, it is not possible to use the Unicode bidi control characters to define direction for paragraphs, since these are inline controls only, and the effect is terminated by a paragraph end.

When capturing text input by a user it is usually necessary to understand the context in which the user was inputting the data to determine the base direction of the input. In HTML, for example, this may be set by the direction inherited from the html tag, or by the user pressing keys to set the base direction for a form field. It is then necessary to find some way of storing the information about base direction or associating it with the string when rendered. Typically, in this situation, any direction changes internal to the string being input are handled by the user and will be captured as part of the string.

3.2.3 Inline changes to base direction

Embedded ranges of text within a single paragraph may need to have a different base direction. For example,

"The title was '!NOITASILANOITANRETNI'."

where the span within the single quotes is in Hebrew/Arabic/Divehi, etc., and needs to have a RTL base direction, instead of the LTR base direction of the surrounding paragraph, in order to place the exclamation mark correctly.

If markup is available to the content author, it is likely to be easier and safer to use markup to indicate such inline ranges (see below). In HTML you would usually use an inline element with a dir attribute to establish the base direction for such runs of text. If you can't mark up the text, such as in HTML's title element, or any environment that handles only plain text content, you have to resort to Unicode's paired control characters to establish the base direction for such an internal range.

Furthermore, inline ranges where the base direction is changed should be isolated from surrounding text, so that the UBA doesn't produce incorrect results due to interference across boundaries. See an example of how this can produce incorrect ordering of things such as text followed by numbers in HTML, or another example of how it can affect lists.

This means that if a content author is using Unicode control codes they should use RLI/LRI...PDI rather than RLE/LRE...PDF.  These isolating codes are fairly new, and applications may not yet support them.

3.2.4 Problems with control characters

Reasons to avoid relying on control characters to set direction include the following:

  1. They are invisible in most editors and are therefore difficult to work with, and can easily lead to orphans and overlapping ranges. They can be particularly difficult to manage when editing bidirectional inline text because it's hard to position the cursor in the correct place. If you ask someone who writes in a right-to-left script, you are likely to find that they dislike using control codes.
  2. Users often don't have the necessary characters available on their keyboard, or have difficulty inputting them.
  3. It is sometimes necessary to choose which to use based on context or the type of the data, and this means that a content author typically needs to select the control codes – specifying control codes in this way for all paragraphs is time-consuming and error-prone.
  4. Processors that extract parts of the data, add to it, or reuse in combination with other text may incorrectly handle the control codes.
  5. Search and comparison algorithms should ignore these characters, but typically don't.

The last two items above may also hold for markup, but implementers often support included markup better than included control codes.

Don't expect users to add control codes at the start and end of every paragraph. That's far too much work.

3.2.5 RLM and LRM

A word about the Unicode characters U+200F RIGHT-TO-LEFT MARK (RLM) and U+200E LEFT-TO-RIGHT MARK (LRM) is warranted at this point.

The first point to be clear about is that neither RLM nor LRM establish the base direction for a range of text.  They are simply invisible characters with strong directional properties.

This means that you cannot use RLM for example, to make the text W3C appear to the left of the Hebrew text in the following example.

The title is "פעילות הבינאום, W3C".

For this you can only use metadata or the paired control characters.

Of course, if you are detecting base direction using first-strong heuristics then RLM and LRM can be useful for setting the base direction where the text in question begins with something that would otherwise give the wrong result, eg.

"نشاط التدويل" is how you say "i18n Activity" in Arabic.

Here an LRM could be placed at the start of the text, before the strong RTL Arabic characters, to prevent the algorithm from assuming that the text should be right-to-left. (Remember that if metadata is used to set the base direction, that character is ignored, unless the metadata specifically says that first-strong heuristics should be used.)

3.2.6 Base direction and language

§

Do not assume that direction can be determined from language information.

The following are all reasons you cannot use language tags to provide information about base direction:

  1. you can't produce the auto value with language tags.
  2. some languages are written with both RTL and LTR scripts.
  3. the only reliable part of the language tag that would indicate the base direction is the script tag, but BCP47 recommends that you suppress the use of the script tag for languages that don't usually need it, such as Hebrew (suppressscript: Hebr). Languages, such as Persian, that are usually written in a RTL script may be written in transcribed form, and it's not possible to guarantee that the necessary script tag would be present to carry the directional information. In summary, you won't be able to rely on people supplying script tags as part of the language information in order to influence direction.
  4. the incidence of use of language tags and base direction markers often don't coincide.
  5. they are not semantically equivalent.

3.3 Base direction values

§

Values for the default base direction should include left-to-right, right-to-left, and auto.

The auto value allows automatic detection of the base direction for a piece of text. For example, the auto value of dir in HTML looks for the first strong directional character in the text, but ignores certain items of markup also, to guess the base direction of the text. Note that automatic detection algorithms are far from perfect. First-strong detection is unable to correctly identify text that is really right-to-left, but that begins with a strong LTR character. Algorithms that attempt to judge the base direction based on contents of the text are also problematic. The best scenario is one where the base direction is known and declared.

3.4 Handling direction in markup

This section is about defining approaches to bidi handling that work with resources that organises content using markup. Some of the recommendations are different from those for handling strings on the Web (see 3.5 Handling base direction for strings).

3.4.1 Setting the default base direction

§

The spec should indicate how to define a default base direction for the resource as a whole, ie. set the overall base direction.

§

The default base direction, in the absence of other information, should be LTR.

3.4.2 Establishing the base direction for paragraphs

§

The content author must be able to indicate parts of the text where the base direction changes. At the block level, this should be achieved using attributes or metadata, and should not rely on Unicode control characters.

Relying on Unicode control characters to establish direction for every block is not feasible because line breaks terminate the effect of such control characters. It also makes the data much less stable, and unnecessarily difficult to manage if control characters have to appear at every point where they would be needed.

§

It must be possible to also set the direction for content fragments to auto. This means that the base direction will be determined by examining the content itself.

A typical approach here would be to set the direction based on the first strong directional character outside of any markup, but this is not the only possible method. The algorithm used to determine directionality when direction is set to auto should match that expected by the receiver.

The first-strong algorithm looks for the first character in the paragraph with a strong directional property according to the Unicode definitions. It then sets the base direction of the paragraph according to the direction of that character.

Note that the first-strong algorithm may incorrectly guess the direction of the paragraph when the first character is not typical of the rest of the paragraph, such as when a RTL paragraph or line starts with a LTR brand name or technical term.

For additional information about algorithms for detecting direction, see Estimation algorithms in the document where this was discussed with reference to HTML.

§

If the overall base direction is set to auto for plain text, the direction of content paragraphs should be determined on a paragraph by paragraph basis.

§

To indicate the sides of a block of text relative to the start and end of its contained lines, use 'block-start' and 'block-end', rather than 'top' and 'bottom'.

§

To indicate the start/end of a line you should use 'start' and 'end', or 'inline-start' and 'inline-end', rather than 'left' and 'right'.

§

Provide dedicated attributes for control of base direction and bidirectional overrides; do not rely on the user applying style properties to arbitrary markup to achieve bidi control.

For example, HTML has a dir attribute that is capable of managing base direction without assistance from CSS styling. XML formats should define dedicated markup to represent directional information, even if they need CSS to achieve the required display, since the text may be used in other ways.

Style sheets such as CSS may not always be used with the data, or carried with the data when it is syndicated, etc. Directional information is fundamentally important to correct display of the data, and should be associated more closely and more permanently with the markup or data.

3.5 Handling base direction for strings

Note

The information in this section is pulled from Requirements for Language and Direction Metadata in Data Formats. That document is still being written, so these guidelines are likely to change at any time.

§

Provide metadata constructs that can be used to indicate the base direction of any natural language string.

§

Specify that consumers of strings should use heuristics, preferably based on the Unicode Standard first-strong algorithm, to detect the base direction of a string except where metadata is provided.

§

Where possible, define a field to indicate the default direction for all strings in a given resource or document.

§

Do NOT assume that a creating a document-level default without the ability to change direction for any string is sufficient.

§

If metadata is not available due to legacy implementations and cannot otherwise be provided, specifications MAY allow a base direction to be interpolated from available language metadata.

§

Specifications MUST NOT require the production or use of paired bidi controls.

3.6 Setting base direction for inline or substring text

'Inline text' here has a readily understandable meaning in markup. It also applies to strings (eg. in JSON, CVS, or other plain text formats), meaning runs of characters which don't include all the characters in the string.

§

It must be possible to indicate spans of inline text where the base direction changes. If markup is available, this is the preferred method. Otherwise your specification must require that Unicode control characters are recognized by the receiving application, and correctly implemented.

§

It must be possible to also set the direction for a span to auto. This means that the base direction will be determined by examining the content itself. A typical approach here would be to set the direction based on the first strong directional character outside of any markup.

The first-strong algorithm looks for the first character in the paragraph with a strong directional property according to the Unicode definitions. It then sets the base direction of the paragraph according to the direction of that character.

Note that the first-strong algorithm may incorrectly guess the direction of the paragraph when the first character is not typical of the rest of the paragraph, such as when a RTL paragraph or line starts with a LTR brand name or technical term.

For additional information about algorithms for detecting direction, see Estimation algorithms in the document where this was discussed with reference to HTML.

§

If users use Unicode bidirectional control characters, the isolating RLI/LRI/FSI with PDI characters must be supported by the application and recommended (rather than RLE/LRE with PDF) by the spec.

§

Use of RLM/LRM should be appropriate, and expectations of what those controls can and cannot do should be clear in the spec.

The Unicode bidirectional control characters U+200F RIGHT-TO-LEFT MARK and U+200E LEFT-TO-RIGHT MARK are not sufficient on their own to manage bidirectional text. They cannot produce a different base direction for embedded text. For that you need to be able to indicate the start and end of the range of the embedded text.  This is best done by markup, if available, or failing that using the other Unicode bidirectional controls mentioned just above.

§

For markup, provide dedicated attributes for control of base direction and bidirectional overrides; do not rely on the user applying style properties to arbitrary markup to achieve bidi control.

§

For markup, allow bidi attributes on all inline elements in markup that contain text.

§

For markup, provide attributes that allow the user to (a) create an embedded base direction or (b) override the bidirectional algorithm altogether; the attribute should allow the user to set the direction to LTR or RTL or the aforementioned Auto in either of these two scenarios.

4. Characters

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Choosing a definition of 'character'
  • Specifications SHOULD use specific terms, when available, instead of the general term 'character'. more
  • When specifications use the term 'character' the specifications MUST define which meaning they intend, and SHOULD explicitly define the term 'character' to mean a Unicode code point. more
  • Specifications, software and content MUST NOT require or depend on a one-to-one relationship between characters and units of physical storage. more
  • Specifications, software and content MUST NOT require or depend on a one-to-one correspondence between characters and the sounds of a language. more
  • Specifications, software and content MUST NOT require or depend on a one-to-one mapping between characters and units of displayed text. more
  • Specifications and software MUST NOT require nor depend on a single keystroke resulting in a single character, nor that a single character be input with a single keystroke (even with modifiers), nor that keyboards are the same all over the world. more
Defining a Reference Processing Model
  • Textual data objects defined by protocol or format specifications MUST be in a single character encoding. more
  • All specifications that involve processing of text MUST specify the processing of text according to the Reference Processing Model described by the rest of the recommendations in this list. more
  • Specifications MUST define text in terms of Unicode characters, not bytes or glyphs. more
  • For their textual data objects specifications MAY allow use of any character encoding which can be transcoded to a Unicode encoding form. more
  • Specifications MAY choose to disallow or deprecate some character encodings and to make others mandatory. Independent of the actual character encoding, the specified behavior MUST be the same as if the processing happened as follows: (a) The character encoding of any textual data object received by the application implementing the specification MUST be determined and the data object MUST be interpreted as a sequence of Unicode characters - this MUST be equivalent to transcoding the data object to some Unicode encoding form, adjusting any character encoding label if necessary, and receiving it in that Unicode encoding form, (b) All processing MUST take place on this sequence of Unicode characters, (c) If text is output by the application, the sequence of Unicode characters MUST be encoded using a character encoding chosen among those allowed by the specification. more
  • If a specification is such that multiple textual data objects are involved (such as an XML document referring to external parsed entities), it MAY choose to allow these data objects to be in different character encodings. In all cases, the Reference Processing Model MUST be applied to all textual data objects. more
Including and excluding character ranges
  • Specifications SHOULD NOT arbitrarily exclude code points from the full range of Unicode code points from U+0000 to U+10FFFF inclusive. more
  • Specifications MUST NOT allow code points above U+10FFFF. more
  • Specifications SHOULD NOT allow the use of codepoints reserved by Unicode for internal use. more
  • Specifications MUST NOT allow the use of surrogate code points. more
  • Specifications SHOULD exclude compatibility characters in the syntactic elements (markup, delimiters, identifiers) of the formats they define. more
  • Specifications SHOULD allow the full range of Unicode for user-defined values. more
Using the Private Use Area
  • Specifications MUST NOT require the use of private use area characters with particular assignments. more
  • Specifications MUST NOT require the use of mechanisms for defining agreements of private use code points. more
  • Specifications and implementations SHOULD NOT disallow the use of private use code points by private agreement. more
  • Specifications MAY define markup to allow the transmission of symbols not in Unicode or to identify specific variants of Unicode characters. more
  • Specifications SHOULD allow the inclusion of or reference to pictures and graphics where appropriate, to eliminate the need to (mis)use character-oriented mechanisms for pictures or graphics. more
Choosing character encodings
  • Specifications MUST either specify a unique character encoding, or provide character encoding identification mechanisms such that the encoding of text can be reliably identified. more
  • When designing a new protocol, format or API, specifications SHOULD require a unique character encoding. more
  • When basing a protocol, format, or API on a protocol, format, or API that already has rules for character encoding, specifications SHOULD use rather than change these rules. more
  • When a unique character encoding is required, the character encoding MUST be UTF-8, or UTF-16. more
  • Specifications SHOULD avoid using the terms 'character set' and 'charset' to refer to a character encoding, except when the latter is used to refer to the MIME charset parameter or its IANA-registered values. The term 'character encoding', or in specific cases the terms 'character encoding form' or 'character encoding scheme', are RECOMMENDED. more
  • If the unique encoding approach is not taken, specifications SHOULD require the use of the IANA charset registry names, and in particular the names identified in the registry as 'MIME preferred names', to designate character encodings in protocols, data formats and APIs. more
  • Character encodings that are not in the IANA registry SHOULD NOT be used, except by private agreement. more
  • If an unregistered character encoding is used, the convention of using 'x-' at the beginning of the name MUST be followed. more
  • If the unique encoding approach is not chosen, specifications MUST designate at least one of the UTF-8 and UTF-16 encoding forms of Unicode as admissible character encodings and SHOULD choose at least one of UTF-8 or UTF-16 as required encoding forms (encoding forms that MUST be supported by implementations of the specification). more
  • Specifications that require a default encoding MUST define either UTF-8 or UTF-16 as the default, or both if they define suitable means of distinguishing them. more
Identifying character encodings
  • Specifications MUST NOT propose the use of heuristics to determine the encoding of data. more
  • Specifications MUST define conflict-resolution mechanisms (e.g. priorities) for cases where there is multiple or conflicting information about character encoding. more
Designing character escapes
  • Specifications should provide a mechanism for escaping characters, particularly those which are invisible or ambiguous. more
  • Specifications SHOULD NOT invent a new escaping mechanism if an appropriate one already exists. more
  • The number of different ways to escape a character SHOULD be minimized (ideally to one). more
  • Escape syntax SHOULD require either explicit end delimiters or a fixed number of characters in each character escape. Escape syntaxes where the end is determined by any character outside the set of characters admissible in the character escape itself SHOULD be avoided. more
  • Whenever specifications define character escapes that allow the representation of characters using a number, the number MUST represent the Unicode code point of the character and SHOULD be in hexadecimal notation. more
  • Escaped characters SHOULD be acceptable wherever their unescaped forms are; this does not preclude that syntax-significant characters, when escaped, lose their significance in the syntax. In particular, if a character is acceptable in identifiers and comments, then its escaped form should also be acceptable. more
Storing text
  • Protocols, data formats and APIs MUST store, interchange or process text data in logical order. more
  • Independent of whether some implementation uses logical selection or visual selection, characters selected MUST be kept in logical order in storage. more
  • Specifications of protocols and APIs that involve selection of ranges SHOULD provide for discontiguous logical selections, at least to the extent necessary to support implementation of visual selection on screen on top of those protocols and APIs. more
Defining 'string'
  • Specifications SHOULD NOT define a string as a 'byte string'. more
  • The 'character string' definition SHOULD be used by most specifications. more
Referring to Unicode characters
  • Use U+XXXX syntax to represent Unicode code points in the specification. more
Referencing the Unicode Standard
  • Since specifications in general need both a definition for their characters and the semantics associated with these characters, specifications SHOULD include a reference to the Unicode Standard, whether or not they include a reference to ISO/IEC 10646. more
  • A generic reference to the Unicode Standard MUST be made if it is desired that characters allocated after a specification is published are usable with that specification. A specific reference to the Unicode Standard MAY be included to ensure that functionality depending on a particular version is available and will not change over time. more
  • All generic references to the Unicode Standard MUST refer to the latest version of the Unicode Standard available at the date of publication of the containing specification. more
  • All generic references to ISO/IEC 10646 MUST refer to the latest version of ISO/IEC 10646 available at the date of publication of the containing specification. more

The term character is often used to mean different things in different contexts: it can variously refer to the visual, logical, or byte-level representation of a given piece of text. This makes the term too imprecise to use when specifying algorithms, protocols, or document formats. Understanding how characters are defined and encoded in computing systems, along with the associated terminology used to make such specification unambiguous, is thus a necessary prerequisite to discussing the processing of string data.

The visual manifestation of a "character"—the shape most people mean when they say "character"—is what we call a user-perceived character. These visual building blocks are usually perceived to be a single unit of the visible text.

At their simplest, user-perceived characters are a single shape that can be tied one-to-one to the underlying computing representation. But a user-perceived character can be formed, in some scripts, from more than one character. And a given logical character can take many different shapes due to such influences as font selection, style, or the surrounding context (such as adjacent characters). In some cases, a single user-perceived character might be formed from a long sequence of logical characters. And some logical characters (so-called "combining marks") are always used in conjunction with another character.

When user-perceived characters are represented visibly (on screen or in print), they are represented by individual rendering units. This visual unit is called a grapheme (the word glyph is also used). Graphemes are the visual units found in fonts and rendering software.

Graphemes are encoded into computer systems using "logical characters". A character set is a set of logical characters: a specific collection of characters that can be used together to encode text. The most important character set is the Universal Character Set, also known as [Unicode]. This character set includes all of the characters used to encode text, including historical or extinct writing systems as well as modern usage, private use, typesetting symbols, and other things, such as the emoji. Other character sets are defined subsets of Unicode. In Unicode, a 'character' is a single abstract logical unit of text. Each character in Unicode is assigned a unique integer number between 0x0000 and 0x10FFFF, which is called its code point. The term code point therefore unambiguously refers to a single logical character and its integer representation.

§

Specifications SHOULD explicitly define the term 'character' to mean a Unicode code point.

The relationship between code points and graphemes can be complex. In most cases, a code point sequence that forms a single grapheme should be treated as a single textual unit. For example, when cursoring across text, an entire grapheme should select together. It shouldn't be possible to cursor into the "middle" of a grapheme or delete only a part of user-perceived character. Because the relationship is not one-to-one between code points and graphemes and because the relationship can be somewhat complex, [Unicode] defines a specific type of grapheme: the extended grapheme cluster which most closely matches the mapping of the underlying logical character sequence to a user-perceived character. When referring to 'graphemes' in this document, we mean extended grapheme clusters (unless otherwise called out).

Another example of the complex relationship between code points and graphemes are certain emoji. The emoji character for "family" has a code point in Unicode: 👪 [U+1F46A FAMILY]. It can also be formed by using using a sequence of code points: U+1F468 U+200D U+1F469 U+200D U+1F466. Altering or adding other emoji characters can alter the composition of the family. For example the sequence 👨‍👩‍👧‍👧 U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467 results in a composed emoji character for a "family: man, woman, girl, girl" on systems that support this kind of composition. Many common emoji can only be formed using sequences of code points, but should be treated as a single user-perceived character when displaying or processing the text. You wouldn't want to put a line-break in the middle of the family!

Unicode code points are just abstract integer values: they are not the values actually present in the memory of the computer or serialized on the wire. When processing text, computers use an array of fixed-size integer units. One such common unit is the byte (or octet, since bytes have 8 bits per unit). There are also 16-bit, 32-bit, or other size units. In many programming languages, the unit is called a char, which suggests that strings are made of "characters". We use the term code unit to refer unambiguously to the programming and serialized representation of characters. For example, in C, a char is generally an 8-bit byte: each char is a 8-bit code unit. In Java or Javascript, a char is a 16-bit value.

A set of rules for converting code points to or from code units is called a character encoding form (or just "character encoding" for short.

4.1 Choosing a definition of 'character'

§

Specifications SHOULD use specific terms, when available, instead of the general term 'character'.

§

When specifications use the term 'character' the specifications MUST define which meaning they intend, and SHOULD explicitly define the term 'character' to mean a Unicode code point.

§

Specifications, software and content MUST NOT require or depend on a one-to-one relationship between characters and units of physical storage.

§

Specifications, software and content MUST NOT require or depend on a one-to-one correspondence between characters and the sounds of a language.

§

Specifications, software and content MUST NOT require or depend on a one-to-one mapping between characters and units of displayed text.

§

Specifications and software MUST NOT require nor depend on a single keystroke resulting in a single character, nor that a single character be input with a single keystroke (even with modifiers), nor that keyboards are the same all over the world.

4.2 Defining a Reference Processing Model

§

Textual data objects defined by protocol or format specifications MUST be in a single character encoding.

§

All specifications that involve processing of text MUST specify the processing of text according to the Reference Processing Model described by the rest of the recommendations in this list.

§

Specifications MUST define text in terms of Unicode characters, not bytes or glyphs.

§

For their textual data objects specifications MAY allow use of any character encoding which can be transcoded to a Unicode encoding form.

§

Specifications MAY choose to disallow or deprecate some character encodings and to make others mandatory. Independent of the actual character encoding, the specified behavior MUST be the same as if the processing happened as follows: (a) The character encoding of any textual data object received by the application implementing the specification MUST be determined and the data object MUST be interpreted as a sequence of Unicode characters - this MUST be equivalent to transcoding the data object to some Unicode encoding form, adjusting any character encoding label if necessary, and receiving it in that Unicode encoding form, (b) All processing MUST take place on this sequence of Unicode characters, (c) If text is output by the application, the sequence of Unicode characters MUST be encoded using a character encoding chosen among those allowed by the specification.

§

If a specification is such that multiple textual data objects are involved (such as an XML document referring to external parsed entities), it MAY choose to allow these data objects to be in different character encodings. In all cases, the Reference Processing Model MUST be applied to all textual data objects.

4.3 Including and excluding character ranges

§

Specifications SHOULD NOT arbitrarily exclude code points from the full range of Unicode code points from U+0000 to U+10FFFF inclusive.

§

Specifications MUST NOT allow code points above U+10FFFF.

§

Specifications SHOULD NOT allow the use of codepoints reserved by Unicode for internal use.

§

Specifications MUST NOT allow the use of surrogate code points.

§

Specifications SHOULD exclude compatibility characters in the syntactic elements (markup, delimiters, identifiers) of the formats they define.

§

Specifications SHOULD allow the full range of Unicode for user-defined values.

4.4 Using the Private Use Area

§

Specifications MUST NOT require the use of private use area characters with particular assignments.

§

Specifications MUST NOT require the use of mechanisms for defining agreements of private use code points.

§

Specifications and implementations SHOULD NOT disallow the use of private use code points by private agreement.

§

Specifications MAY define markup to allow the transmission of symbols not in Unicode or to identify specific variants of Unicode characters.

§

Specifications SHOULD allow the inclusion of or reference to pictures and graphics where appropriate, to eliminate the need to (mis)use character-oriented mechanisms for pictures or graphics.

4.5 Choosing character encodings

§

Specifications MUST either specify a unique character encoding, or provide character encoding identification mechanisms such that the encoding of text can be reliably identified.

§

When designing a new protocol, format or API, specifications SHOULD require a unique character encoding.

§

When basing a protocol, format, or API on a protocol, format, or API that already has rules for character encoding, specifications SHOULD use rather than change these rules.

§

When a unique character encoding is required, the character encoding MUST be UTF-8, or UTF-16.

Note

The above guideline needs further consideration: utf-16 and utf-32 are not recommended these days. UTF-8 is the recommended encoding.

§

Specifications SHOULD avoid using the terms 'character set' and 'charset' to refer to a character encoding, except when the latter is used to refer to the MIME charset parameter or its IANA-registered values. The term 'character encoding', or in specific cases the terms 'character encoding form' or 'character encoding scheme', are RECOMMENDED.

§

If the unique encoding approach is not taken, specifications SHOULD require the use of the IANA charset registry names, and in particular the names identified in the registry as 'MIME preferred names', to designate character encodings in protocols, data formats and APIs.

Note

The above guideline needs further consideration: the list of character encodings recommended for Web specifications is listed in the Encoding specification.

§

Character encodings that are not in the IANA registry SHOULD NOT be used, except by private agreement.

§

If an unregistered character encoding is used, the convention of using 'x-' at the beginning of the name MUST be followed.

§

If the unique encoding approach is not chosen, specifications MUST designate at least one of the UTF-8 and UTF-16 encoding forms of Unicode as admissible character encodings and SHOULD choose at least one of UTF-8 or UTF-16 as required encoding forms (encoding forms that MUST be supported by implementations of the specification).

§

Specifications that require a default encoding MUST define either UTF-8 or UTF-16 as the default, or both if they define suitable means of distinguishing them.

4.6 Identifying character encodings

§

Specifications MUST NOT propose the use of heuristics to determine the encoding of data.

§

Specifications MUST define conflict-resolution mechanisms (e.g. priorities) for cases where there is multiple or conflicting information about character encoding.

4.7 Designing character escapes

§

Specifications should provide a mechanism for escaping characters, particularly those which are invisible or ambiguous.

It is generally recommended that character escapes be provided so that difficult to enter or edit sequences can be introduced using a plain text editor. Escape sequences are particularly useful for invisible or ambiguous Unicode characters, including zero-width spaces, soft-hyphens, various bidi controls, mongolian vowel separators, etc.

For advice on use of escapes in markup, but which is mostly generalisable to other formats, see Using character escapes in markup and CSS.

§

Specifications SHOULD NOT invent a new escaping mechanism if an appropriate one already exists.

§

The number of different ways to escape a character SHOULD be minimized (ideally to one).

§

Escape syntax SHOULD require either explicit end delimiters or a fixed number of characters in each character escape. Escape syntaxes where the end is determined by any character outside the set of characters admissible in the character escape itself SHOULD be avoided.

§

Whenever specifications define character escapes that allow the representation of characters using a number, the number MUST represent the Unicode code point of the character and SHOULD be in hexadecimal notation.

§

Escaped characters SHOULD be acceptable wherever their unescaped forms are; this does not preclude that syntax-significant characters, when escaped, lose their significance in the syntax. In particular, if a character is acceptable in identifiers and comments, then its escaped form should also be acceptable.

4.8 Storing text

§

Protocols, data formats and APIs MUST store, interchange or process text data in logical order.

§

Independent of whether some implementation uses logical selection or visual selection, characters selected MUST be kept in logical order in storage.

§

Specifications of protocols and APIs that involve selection of ranges SHOULD provide for discontiguous logical selections, at least to the extent necessary to support implementation of visual selection on screen on top of those protocols and APIs.

4.9 Defining 'string'

§

Specifications SHOULD NOT define a string as a 'byte string'.

§

The 'character string' definition SHOULD be used by most specifications.

4.10 Referring to Unicode characters

§

Use U+XXXX syntax to represent Unicode code points in the specification.

The U+XXXX format is well understood when referring to Unicode code points in a specification. These are space separated when appearing in a sequence. No additional decoration is needed. Note that a code point may contain four, five, or six hexadecimal digits. When fewer than four digits are needed, the code point number is zero filled. E.g. U+0020.

4.11 Referencing the Unicode Standard

§

Since specifications in general need both a definition for their characters and the semantics associated with these characters, specifications SHOULD include a reference to the Unicode Standard, whether or not they include a reference to ISO/IEC 10646.

§

A generic reference to the Unicode Standard MUST be made if it is desired that characters allocated after a specification is published are usable with that specification. A specific reference to the Unicode Standard MAY be included to ensure that functionality depending on a particular version is available and will not change over time.

§

All generic references to the Unicode Standard MUST refer to the latest version of the Unicode Standard available at the date of publication of the containing specification.

§

All generic references to ISO/IEC 10646 MUST refer to the latest version of ISO/IEC 10646 available at the date of publication of the containing specification.

5. Text-processing

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Choosing text units for segmentation, indexing, etc.
  • The character string is RECOMMENDED as a basis for string indexing. more
  • Grapheme clusters MAY be used as a basis for string indexing in applications where user interaction is the primary concern. more
  • Specifications that define indexing in terms of grapheme clusters MUST either: (a) define grapheme clusters in terms of extended grapheme clusters as defined in Unicode Standard Annex #29, Unicode Text Segmentation (UTR #29), or (b) define specifically how tailoring is applied to the indexing operation. more
  • The use of byte strings for indexing is NOT RECOMMENDED. more
  • A UTF-16 code unit string is NOT RECOMMENDED as a basis for string indexing, even if this results in a significant improvement in the efficiency of internal operations when compared to the use of character string. more
  • Specifications that need a way to identify substrings or point within a string SHOULD consider ways other than string indexing to perform this operation. more
  • Specifications SHOULD understand and process single characters as substrings, and treat indices as boundary positions between counting units, regardless of the choice of counting units. more
  • Specifications of APIs SHOULD NOT specify single characters or single 'units of encoding' as argument or return types. more
  • When the positions between the units are counted for string indexing, starting with an index of 0 for the position at the start of the string is the RECOMMENDED solution, with the last index then being equal to the number of counting units in the string. more
Matching string identity for identifiers and syntactic content
  • String identity matching for identifiers and syntactic content should involve the following steps: (a) Ensure the strings to be compared constitute a sequence of Unicode code points (b) Expand all character escapes and includes (c) Perform any appropriate case-folding and Unicode normalization step (d) Perform any additional matching tailoring specific to the specification, and (e) Compare the resulting sequences of code points for identity. more
  • The default recommendation for matching strings in identifiers and syntactic content is to do no normalization (ie. case folding or Unicode Normalization) of content. more
  • 'ASCII case fold' and 'Unicode canonical case fold' approaches should only be used in special circumstances. more
  • A 'Unicode compatibility case fold' approach should not be used. more
  • Specifications of vocabularies MUST define the boundaries between syntactic content and character data as well as entity boundaries (if the language has any include mechanism). more
Working with Unicode Normalization
  • Specifications SHOULD NOT specify a Unicode normalization form for encoding, storage, or interchange of a given vocabulary. more
  • Implementations MUST NOT alter the normalization form of textual data being exchanged, read, parsed, or processed except when required to do so as a side-effect of text transformation such as transcoding the content to a Unicode character encoding, case folding, or other user-initiated change, as consumers or the content itself might depend on the de-normalized representation. more
  • Specifications SHOULD NOT specify compatibility normalization forms (NFKC, NFKD). more
  • Specifications MUST document or provide a health-warning if canonically equivalent but disjoint Unicode character sequences represent a security issue. more
  • Where operations can produce denormalized output from normalized text input, specifications MUST define whether the resulting output is required to be normalized or not. Specifications MAY state that performing normalization is optional for some operations; in this case the default SHOULD be that normalization is performed, and an explicit option SHOULD be used to switch normalization off. more
  • Specifications that require normalization MUST NOT make the implementation of normalization optional. more
  • Normalization-sensitive operations MUST NOT be performed unless the implementation has first either confirmed through inspection that the text is in normalized form or it has re-normalized the text itself. Private agreements MAY be created within private systems which are not subject to these rules, but any externally observable results MUST be the same as if the rules had been obeyed. more
  • A normalizing text-processing component which modifies text and performs normalization-sensitive operations MUST behave as if normalization took place after each modification, so that any subsequent normalization-sensitive operations always behave as if they were dealing with normalized text. more
  • Specifications that perform comparison or matching of string values SHOULD specify the appropriate note or warning regarding Unicode normalization. more
Case folding
  • Specifications and implementations that define string matching as part of the definition of a format, protocol, or formal language (which might include operations such as parsing, matching, tokenizing, etc.) MUST define the criteria and matching forms used. These MUST be one of: (a) case-sensitive (b) Unicode case-insensitive using Unicode full case-folding (c) ASCII case-insensitive. more
  • Case-sensitive matching is RECOMMENDED for matching syntactic content, including user-defined values. more
  • Specifications that define case-insensitive matching in vocabularies that include more than the Basic Latin (ASCII) range of Unicode MUST specify Unicode full casefold matching. more
  • Specifications that define case-insensitive matching in vocabularies limited to the Basic Latin (ASCII) subset of Unicode MAY specify ASCII case-insensitive matching. more
  • If language-sensitive case-sensitive matching is specified, Unicode case mappings SHOULD be tailored according to language and the source of the language used for each tailoring MUST be specified. more
  • Specifications that define case-insensitive matching in vocabularies SHOULD NOT specify language-sensitive case-insensitive matching. more
Truncating or limiting the length of strings
  • Specifications SHOULD NOT limit the size of data fields unless there is a specific practical or technical limitation. more
  • Specifications that limit the length of a string MUST specify which type of unit (extended grapheme clusters, Unicode code points, or code units) the length limit uses. more
  • Specifications that limit the length of a string SHOULD specify the length in terms of Unicode code points. more
  • If a specification sets a length limit in code units (such as bytes), it MUST specify that truncation can only occur on code point boundaries. more
  • Specifications that limit the length of a string SHOULD require truncation on grapheme boundaries, as truncation in the midst of a combining or joining sequence can alter the meaning of the string. more
  • If a specification specifies a length limit, it SHOULD specify that any string that is truncated include an indicator, such as ellipses, that the string has been altered. more
  • When specifying a length limitation in code units (such as bytes), specifications SHOULD set the maximum length in a way that accommodates users whose language requires multibyte code unit sequences. more
Working with file and path names
  • Specify the UTF-8 [Unicode] encoding for the storage and processing of file names and file paths. more
  • File names SHOULD be restricted to 255 bytes in length. more
  • Path names SHOULD be restricted to 65535 bytes in length. more
  • File name and path name definitions MUST NOT use the following Unicode code points. more
Specifying sort and search functionality
  • Software that sorts or searches text for users SHOULD do so on the basis of appropriate collation units and ordering rules for the relevant language and/or application. more
  • Where searching or sorting is done dynamically, particularly in a multilingual environment, the 'relevant language' SHOULD be determined to be that of the current user, and may thus differ from user to user. more
  • Software that allows users to sort or search text SHOULD allow the user to select alternative rules for collation units and ordering. more
  • Specifications and implementations of sorting and searching algorithms SHOULD accommodate text that contains any character in Unicode. more

5.1 Choosing text units for segmentation, indexing, etc.

There are many situations where a software process needs to access a substring or to point within a string and does so by the use of indices, i.e. numeric "positions" within a string. Where such indices are exchanged between components of the Web, there is a need for an agreed-upon definition of string indexing in order to ensure consistent behavior. The two main questions that arise are: "What is the unit of counting?" and "Do we start counting at 0 or 1?".

§

The character string is RECOMMENDED as a basis for string indexing.

§

Grapheme clusters MAY be used as a basis for string indexing in applications where user interaction is the primary concern.

§

Specifications that define indexing in terms of grapheme clusters MUST either: (a) define grapheme clusters in terms of extended grapheme clusters as defined in Unicode Standard Annex #29, Unicode Text Segmentation (UTR #29), or (b) define specifically how tailoring is applied to the indexing operation.

§

The use of byte strings for indexing is NOT RECOMMENDED.

§

A UTF-16 code unit string is NOT RECOMMENDED as a basis for string indexing, even if this results in a significant improvement in the efficiency of internal operations when compared to the use of character string.

A counter-example is the use of UTF-16 in DOM Level 1. The use of UTF-16 code points is discouraged because it leaves open the possibility of an index occuring between two surrogate characters, which would cause significant problems (see 5.5 Truncating or limiting the length of strings).

§

Specifications that need a way to identify substrings or point within a string SHOULD consider ways other than string indexing to perform this operation.

§

Specifications SHOULD understand and process single characters as substrings, and treat indices as boundary positions between counting units, regardless of the choice of counting units.

§

Specifications of APIs SHOULD NOT specify single characters or single 'units of encoding' as argument or return types.

§

When the positions between the units are counted for string indexing, starting with an index of 0 for the position at the start of the string is the RECOMMENDED solution, with the last index then being equal to the number of counting units in the string.

5.2 Matching string identity for identifiers and syntactic content

§

String identity matching for identifiers and syntactic content should involve the following steps: (a) Ensure the strings to be compared constitute a sequence of Unicode code points (b) Expand all character escapes and includes (c) Perform any appropriate case-folding and Unicode normalization step (d) Perform any additional matching tailoring specific to the specification, and (e) Compare the resulting sequences of code points for identity.

§

The default recommendation for matching strings in identifiers and syntactic content is to do no normalization (ie. case folding or Unicode Normalization) of content.

§

'ASCII case fold' and 'Unicode canonical case fold' approaches should only be used in special circumstances.

§

A 'Unicode compatibility case fold' approach should not be used.

§

Specifications of vocabularies MUST define the boundaries between syntactic content and character data as well as entity boundaries (if the language has any include mechanism).

5.3 Working with Unicode Normalization

§

Specifications SHOULD NOT specify a Unicode normalization form for encoding, storage, or interchange of a given vocabulary.

§

Implementations MUST NOT alter the normalization form of textual data being exchanged, read, parsed, or processed except when required to do so as a side-effect of text transformation such as transcoding the content to a Unicode character encoding, case folding, or other user-initiated change, as consumers or the content itself might depend on the de-normalized representation.

§

Specifications SHOULD NOT specify compatibility normalization forms (NFKC, NFKD).

§

Specifications MUST document or provide a health-warning if canonically equivalent but disjoint Unicode character sequences represent a security issue.

§

Where operations can produce denormalized output from normalized text input, specifications MUST define whether the resulting output is required to be normalized or not. Specifications MAY state that performing normalization is optional for some operations; in this case the default SHOULD be that normalization is performed, and an explicit option SHOULD be used to switch normalization off.

§

Specifications that require normalization MUST NOT make the implementation of normalization optional.

§

Normalization-sensitive operations MUST NOT be performed unless the implementation has first either confirmed through inspection that the text is in normalized form or it has re-normalized the text itself. Private agreements MAY be created within private systems which are not subject to these rules, but any externally observable results MUST be the same as if the rules had been obeyed.

§

A normalizing text-processing component which modifies text and performs normalization-sensitive operations MUST behave as if normalization took place after each modification, so that any subsequent normalization-sensitive operations always behave as if they were dealing with normalized text.

5.3.1 Specifying Unicode Normalization

§

Specifications that perform comparison or matching of string values SHOULD specify the appropriate note or warning regarding Unicode normalization.

The use or adoption of Unicode Normalization in a specification is usually part of defining how matching takes place in a given format or protocol. To help specification authors and implementers understand some of the complexity involved, the Internationalization Working Group has developed a document describing the considerations for the matching and comparison of strings: Character Model for the World Wide Web: String Matching [CHARMOD-NORM].

One of the choices specifications need to make is whether (or not) to require Unicode Normalization as part of matching various "values" defined as part of the specification's vocabulary. Values are commonly part of a document format or protocol's syntax, and include such things as: attribute names or values, element names or values, IDs, and so forth. Specifications that follow the recommendation to not employ normalization as part of matching should include the following Note as a reminder to content authors.

Example note. Necessarily this version is non-specific about what constitutes "values": specifications may wish to be more specific.

Note

This specification does not permit Unicode normalization of values for the purposes of comparison. Values that are visually and semantically identical but use different Unicode character sequences will not match. Content authors are advised to use the same encoding sequence consistently or to avoid potentially troublesome characters when choosing values. For more information, see [CHARMOD-NORM].

Specifications that choose to require require normalization as part of string matching should include the following warning:

Example warning. Necessarily this version is non-specific about what constitutes "values": specifications may wish to be more specific.

Warning

This specification applies Unicode normalization during the matching of values. This can have an effect on the appearance and meaning of the affected text. For more information, see [CHARMOD-NORM].

Contact the I18N WG for alternatives or assistance if the above do not meet your needs or you're not sure about usage.

5.4 Case folding

§

Specifications and implementations that define string matching as part of the definition of a format, protocol, or formal language (which might include operations such as parsing, matching, tokenizing, etc.) MUST define the criteria and matching forms used. These MUST be one of: (a) case-sensitive (b) Unicode case-insensitive using Unicode full case-folding (c) ASCII case-insensitive.

§

Case-sensitive matching is RECOMMENDED for matching syntactic content, including user-defined values.

§

Specifications that define case-insensitive matching in vocabularies that include more than the Basic Latin (ASCII) range of Unicode MUST specify Unicode full casefold matching.

§

Specifications that define case-insensitive matching in vocabularies limited to the Basic Latin (ASCII) subset of Unicode MAY specify ASCII case-insensitive matching.

§

If language-sensitive case-sensitive matching is specified, Unicode case mappings SHOULD be tailored according to language and the source of the language used for each tailoring MUST be specified.

§

Specifications that define case-insensitive matching in vocabularies SHOULD NOT specify language-sensitive case-insensitive matching.

5.5 Truncating or limiting the length of strings

Some specifications, formats, or protocols or their implementations need to specify limits for the size of a given data structure or text field. This could be due to many reasons, such as limits on processing, memory, data structure size, and so forth. When selecting or specifying limits on the length of a given string, specifications or implementations need to ensure that they do not cause corruption in the text.

§

Specifications SHOULD NOT limit the size of data fields unless there is a specific practical or technical limitation.

There are many reasons why a length limit might be needed in a specification or format. Generally length limits correspond to underlying limits in the implementation, such as the use of fixed-size fields in a database or data store, the desire to fit into practical boundaries such as packet size, or some other implementation detail related to storage allocation or efficiency.

When truncating strings, it's necessary to decide what units to use when counting the size of the string. In many cases this is beyond the control of the specification, since the truncation is occuring for some preordained reason. However, when the choice is available, some general guidelines can be applied.

If the limitation is related to the number of display positions, the grapheme count usually corresponds most closely to the expected limit. Note that proportional width fonts, combining marks, complex scripts, and many other factors complicate counting "screen positions". In Web pages, for example, the CSS text-overflow property provides visual truncation without disturbing the content of the text. Attempts to estimate the size of a given piece of text based on the number of Unicode code points or even the number of grapheme clusters is mostly futile.

Otherwise most limits are expressed in terms of code points in Unicode or code units (such as bytes) in a specific character encoding. Code points provides the best user experience, since all Unicode code points are treated identically: if text is truncated after 40 code points, all languages and scripts get the same number of code points to work with. By contrast, when the size limit is expressed in code units such as bytes in UTF-8, users who write in a language that mostly uses ASCII letters get many more characters (code points) for a given size limit than user's whose language is mostly made up of characters that take 2-, 3-, or 4-bytes per code point.

§

Specifications that limit the length of a string MUST specify which type of unit (extended grapheme clusters, Unicode code points, or code units) the length limit uses.

§

Specifications that limit the length of a string SHOULD specify the length in terms of Unicode code points.

§

If a specification sets a length limit in code units (such as bytes), it MUST specify that truncation can only occur on code point boundaries.

Note that this best practice applies equally to specifications based on UTF-16, which uses 16-bit code units, not just to multibyte encodings such as UTF-8.

Specifications or APIs that interact with the [DOM] need to contend with the fact that character data, including operations such as length, substringData, insertData, deleteData, and so forth, is specified using UTF-16 code units, not Unicode code points. This can lead to inappropriate mid-character (code point) truncation. Specifications that reference DOM should specify that string operations not occur inside code points, and, where appropriate avoid starting or ending inside grapheme boundaries. Specifications should also include a health warning for implementers and users.

Example warning. Modify this health warning as appropriate for your specification:

Warning

Arbitrary index values in the DOM may not fall on character or grapheme boundaries. Implementations and users should avoid incorrectly starting or ending operations in the middle of a user-perceived character sequence.

§

Specifications that limit the length of a string SHOULD require truncation on grapheme boundaries, as truncation in the midst of a combining or joining sequence can alter the meaning of the string.

§

If a specification specifies a length limit, it SHOULD specify that any string that is truncated include an indicator, such as ellipses, that the string has been altered.

§

When specifying a length limitation in code units (such as bytes), specifications SHOULD set the maximum length in a way that accommodates users whose language requires multibyte code unit sequences.

5.6 Working with file and path names

Some specifications need to define how file names or file paths are constructed by various implementations. One challenge is building definitions that work consistently when used on the different file systems used by different operating systems. This section contains general guidance when defining restrictions on file names or file paths. It is based on requirements developed in [EPUB-33], as well as implementation experience.

§

Specify the UTF-8 [Unicode] encoding for the storage and processing of file names and file paths.

§

File names SHOULD be restricted to 255 bytes in length.

This restriction is related to limitations found in certain file systems, originally MS-DOS, but also certain Unix file systems—as well as packaging schemes such as PKZIP that depend on these file systems or subsumed their limitations—in which the limit for a specific "path element" (including directory names) is limited to 255 bytes.

§

Path names SHOULD be restricted to 65535 bytes in length.

This restriction is related to limitations found in file systems such as FAT32 or NTFS, which restrict the path length to 32760 (32K) code units in the UTF-16 character encoding. Each UTF-16 code unit takes 16 bits (or 2 bytes), making the limit 65,535 when measured in bytes. Note that a path name limited to 64K bytes in UTF-8 can exceed the path length limits on these file systems, since UTF-8 is a variable width encoding.

§

File name and path name definitions MUST NOT use the following Unicode code points.

These characters are known to cause interoperability problems with various file systems. Specifications and implementations should use an abundance of caution in their file naming when interoperability of content is key. The list of restricted characters is intended to help avoid some known problem areas, but it does not ensure that all other Unicode characters are supported.

  • " [U+0022 QUOTATION MARK]
  • * [U+002A ASTERISK]
  • / [U+002F SOLIDUS]
  • : [U+003A COLON]
  • < [U+003C LESS-THAN SIGN]
  • > [U+003E GREATER-THAN SIGN]
  • \ [U+005C REVERSE SOLIDUS]
  • | [U+007C VERTICAL LINE]
  • U+007F DEL
  • U+E0001 LANGUAGE TAG
  • U+E007F CANCEL TAG
  • Codepoints in the following ranges:
    • C0 Controls [U+0000...U+001F]
    • C1 Controls [U+0080...U+009F]
    • Private Use [U+E000...U+F8FF]
    • Specials [U+FFF0...U+FFFF]
    • Supplementary Private Use [U+F0000...U+FFFFF]
    • Supplementary Private Use [U+100000...U+10FFFF]
  • . [U+002E FULL STOP] as the last character (Note that this includes the file names . and .., which have special meaning to many file systems)
  • All Unicode non-character code points, specifically:
    • The 32 contiguous characters in the Basic Multilingual Plane (U+FDD0 … U+FDEF)
    • The last two code points of the Basic Multilingual Plane (U+FFFE and U+FFFF)
    • The last two code points at the end of the Supplementary Planes (U+1FFFE, U+1FFFF … U+EFFFE, U+EFFFF)

5.7 Specifying sort and search functionality

§

Software that sorts or searches text for users SHOULD do so on the basis of appropriate collation units and ordering rules for the relevant language and/or application.

§

Where searching or sorting is done dynamically, particularly in a multilingual environment, the 'relevant language' SHOULD be determined to be that of the current user, and may thus differ from user to user.

§

Software that allows users to sort or search text SHOULD allow the user to select alternative rules for collation units and ordering.

§

Specifications and implementations of sorting and searching algorithms SHOULD accommodate text that contains any character in Unicode.

6. Resource identifiers

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Basics
  • Resource identifiers must permit the use of characters outside those of plain ASCII. more
  • Specifications MUST define when the conversion from IRI references to URI references (or subsets thereof) takes place, in accordance with Internationalized Resource Identifiers (IRIs). more

6.1 Basics

§

Resource identifiers must permit the use of characters outside those of plain ASCII.

§

Specifications MUST define when the conversion from IRI references to URI references (or subsets thereof) takes place, in accordance with Internationalized Resource Identifiers (IRIs).

Many current specifications already contain provisions in accordance with Internationalized Resource Identifiers (IRIs). For XML 1.0, see Section 4.2.2, External Entities. XML Schema Part 2: Datatypes provides the anyURI datatype (see Section 3.2.17). The XML Linking Language (XLink) provides the href attribute (see Section 5.4, Locator Attribute).

Document formats should allow IRIs to be used; handlers for protocols that do not currently support IRIs can convert the IRI to a URI when the IRI is dereferenced.

7. Markup & syntax

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Defining elements and attributes
  • Do not define attribute values that will contain user readable content. Use elements for such content. more
  • If you do define attribute values containing user readable content, provide a means to indicate directional and language information for that text separately from the text contained in the element. more
  • Provide a way for authors to annotate arbitrary inline content using a span-like element or construct. more
Defining identifiers
  • Specifications that define application internal identifiers (which are never shown to users and are always used for matching or processing within an application or protocol) should limit the content to a printable subset of ASCII. ASCII case-insensitive matching is recommended. more
  • When identifiers are visible or potentially visible to users, specifications should allow the use of non-ASCII Unicode characters, in order to ensure that users in all languages can use the resulting document format or protocol with equal access. Case sensitivity (i.e. no case folding) is recommended. more
  • If application internal identifiers are not restricted to ASCII, specifications should define the characters that are allowed to start and be part of a valid identifier. more
  • Specifications should not allow surrogate code points (U+D800 to U+DFFF) or non-character code points in identifiers. more
  • Specifications should not allow the C0 (U+0000 to U+001F) and C1 (U+0080 to U+009F) control characters in identifiers. more
  • Identifiers should be case-sensitive when non-ASCII characters are allowed and case insensitive when only ASCII characters are allowed. more
  • Application internal identifier fields or values must be wrapped with a localizable display value when displayed to end-users. more
Working with plain text
  • Avoid natural language text in elements or attribute values that only allow for plain text. more
  • Avoid defining attribute values whose content will be natural language text. more
  • Provide a span-like element that can be used for any text content to apply information needed for internationalization. more

7.1 Defining elements and attributes

§

Do not define attribute values that will contain user readable content. Use elements for such content.

§

If you do define attribute values containing user readable content, provide a means to indicate directional and language information for that text separately from the text contained in the element.

§

Provide a way for authors to annotate arbitrary inline content using a span-like element or construct.

7.2 Defining identifiers

A common feature of document formats is the definition of various identifiers. This includes reserved keywords as well as user-defined values. To foster interoperability, implementations need to be able to match identifier values reliably and consistently. For a detailed look at this problem, see Character Model: String Matching [CHARMOD-NORM].

§

Specifications that define application internal identifiers (which are never shown to users and are always used for matching or processing within an application or protocol) should limit the content to a printable subset of ASCII. ASCII case-insensitive matching is recommended.

Sometimes specifications need to define a set of identifiers that content authors interact with or which are meaningful to various types of end-users. Restricting the set of allowable characters to ASCII impedes usability, particularly for speakers of languages that do not use the Latin script or that use characters outside of the ASCII range.

§

When identifiers are visible or potentially visible to users, specifications should allow the use of non-ASCII Unicode characters, in order to ensure that users in all languages can use the resulting document format or protocol with equal access. Case sensitivity (i.e. no case folding) is recommended.

§

If application internal identifiers are not restricted to ASCII, specifications should define the characters that are allowed to start and be part of a valid identifier.

One key issue when defining an identifier namespace or set of identifiers in a new specification is the handling of combining marks and certain other characters (such as joiners or bidi controls) when parsing the document format: special focus needs to be paid to how the identifier can be "tokenized" (separated from the surrounding text). One means of doing this is to restrict the range of characters allowed to start an identifier to ensure that normal text processing doesn't interfere with matching the identifier later.

Unicode Identifier and Pattern Syntax [UAX31] provides one model, used notably in programming languages such as Java or JavaScript. HTML and CSS also provide character range definitions for custom identifiers, such as this EBNF [XML] production:

PCENChar ::=
    "-" | "." | [0-9] | "_" | [a-zA-Z] | #xB7 | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x37D] | 
    [#x37F-#x1FFF] | [#x200C-#x200D] | [#x203F-#x2040] | [#x2070-#x218F] | [#x2C00-#x2FEF] |
    [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
Note

HTML and CSS processing is defined such that Unicode character properties (such as whether a given character is a combining mark) are not considered when parsing identifiers and tokens. This allows identifiers to start with a combining character and still be processed reliably, but a plain text editor might not handle the value identically.

Specifications should exercise care when defining identifiers with regards to the handling of whitespace. Note that there are Unicode horizontal whitespace characters other than the ASCII characters U+0020 SPACE and U+0009 TAB.

§

Specifications should not allow surrogate code points (U+D800 to U+DFFF) or non-character code points in identifiers.

§

Specifications should not allow the C0 (U+0000 to U+001F) and C1 (U+0080 to U+009F) control characters in identifiers.

§

Identifiers should be case-sensitive when non-ASCII characters are allowed and case insensitive when only ASCII characters are allowed.

§

Application internal identifier fields or values must be wrapped with a localizable display value when displayed to end-users.

7.3 Working with plain text

§

Avoid natural language text in elements or attribute values that only allow for plain text.

§

Avoid defining attribute values whose content will be natural language text.

§

Provide a span-like element that can be used for any text content to apply information needed for internationalization.

Internationalization information may include language and base direction metadata, inline changes of language, bidirectional text behavioural changes, translate flags, etc.

8. Typographic support

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Text decoration
  • Text decoration such as underline and overline should allow lines to skip ink. more
  • It should be possible to specify the distance of overlines and underlines from the text. more
Vertical text
  • It should be possible to render text vertically for languages such as Japanese, Chinese, Korean, Mongolian, etc. more
  • Vertical text must support line progression from LTR (eg. Mongolian) and RTL (eg. Japanese). more
  • By default, text decoration, ruby, and the like in vertical text where lines are stacked from left to right (eg. Mongolian) should appear on the same side as for CJK vertical text. Placement should not rely on the before and after line locations. more
  • Vertical writing modes that are equivalent to the vertical- values in CSS (only) should use UTR50 to apply default text orientation of characters. (This does not apply to writing modes that are equivalent to sideways- in CSS.) more
  • By default, glyphs of scripts that are normally horizontal should run along a line in vertical text such that the top of the character is toward the right side of the vertical line, but there should also be a mechanism to allow them to progress down the line in upright orientation. Such a mechanism should use grapheme clusters as a minimum text unit, but where necessary allow syllabic clusters to be treated as a unit when they involve more than one grapheme cluster. more
  • Upright Arabic text in vertical lines should use isolated letter forms and the order of text should read top to bottom. more
  • It should be possible for some sequences of characters (particularly digits) to run horizontally within vertical lines (tate chu yoko). more
  • Writing modes should provide values like sideways-lr and sideways-rl in CSS to allow for vertical rotation of lines of horizontal script text. UTR50 is not applicable for these cases. more
Cursive text
  • Overlaps should not be exposed when transparency is applied to the joined letters in cursive text, such as for Arabic, Mongolian, and N'Ko. more
  • When adding a text stroke or shadow, joined letters should not be separated from their neighbors in cursive script text. more
Setting box positioning coordinates when text direction varies
  • Box positioning coordinates must take into account whether the text is horizontal or vertical. more
Ruby text annotations
  • 'Ruby' style annotations alongside base text should be supported for Chinese, Japanese, Korean and Mongolian text, in both horizontal and vertical writing modes. more
  • Ruby implementations should support zhuyin fuhao (bopomofo) ruby for Traditional Chinese. more
  • Ruby implementations should support a tabular content model (such that ruby contents can be arranged in a sequence approximating to rb rb rt rt). more
  • Ruby implementations should make it possible to use an explicit element for ruby bases, like the rb element in HTML. more
  • Ruby implementations should allow annotations to appear on either or both sides of the base text. more
Miscellaneous
  • Line heights must allow for characters that are taller than English. more
  • Box sizes must allow for text expansion in translation. more
  • Line wrapping should take into account the special rules needed for non-Latin scripts. more
  • Avoid specifying presentational tags, such as b for bold, and i for italic. more

8.1 Text decoration

§

Text decoration such as underline and overline should allow lines to skip ink.

§

It should be possible to specify the distance of overlines and underlines from the text.

Skipping ink for text decoration such as underlines may not be appropriate for some scripts, such as Arabic, which prefers to move the underline further away from the baseline instead.

8.2 Vertical text

§

It should be possible to render text vertically for languages such as Japanese, Chinese, Korean, Mongolian, etc.

§

Vertical text must support line progression from LTR (eg. Mongolian) and RTL (eg. Japanese).

§

By default, text decoration, ruby, and the like in vertical text where lines are stacked from left to right (eg. Mongolian) should appear on the same side as for CJK vertical text. Placement should not rely on the before and after line locations.

§

Vertical writing modes that are equivalent to the vertical- values in CSS (only) should use UTR50 to apply default text orientation of characters. (This does not apply to writing modes that are equivalent to sideways- in CSS.)

§

By default, glyphs of scripts that are normally horizontal should run along a line in vertical text such that the top of the character is toward the right side of the vertical line, but there should also be a mechanism to allow them to progress down the line in upright orientation. Such a mechanism should use grapheme clusters as a minimum text unit, but where necessary allow syllabic clusters to be treated as a unit when they involve more than one grapheme cluster.

§

Upright Arabic text in vertical lines should use isolated letter forms and the order of text should read top to bottom.

§

It should be possible for some sequences of characters (particularly digits) to run horizontally within vertical lines (tate chu yoko).

§

Writing modes should provide values like sideways-lr and sideways-rl in CSS to allow for vertical rotation of lines of horizontal script text. UTR50 is not applicable for these cases.

8.3 Cursive text

§

Overlaps should not be exposed when transparency is applied to the joined letters in cursive text, such as for Arabic, Mongolian, and N'Ko.

§

When adding a text stroke or shadow, joined letters should not be separated from their neighbors in cursive script text.

8.4 Setting box positioning coordinates when text direction varies

§

Box positioning coordinates must take into account whether the text is horizontal or vertical.

It is typical, when localizing a user interface or web page, to create mirror-images for the RTL and LTR versions. For example, it is likely that a box that appears near the left side of a window containing English content would appear near the right side of the window if the content is Arabic or Hebrew. It should preferably automatic for this to change, based on the base direction of the current context, unless there is a strong reason for using absolute geometry. One way to achieve this is to use keywords such as start and end, rather than left and right, to indicate position.

8.5 Ruby text annotations

§

'Ruby' style annotations alongside base text should be supported for Chinese, Japanese, Korean and Mongolian text, in both horizontal and vertical writing modes.

§

Ruby implementations should support zhuyin fuhao (bopomofo) ruby for Traditional Chinese.

§

Ruby implementations should support a tabular content model (such that ruby contents can be arranged in a sequence approximating to rb rb rt rt).

§

Ruby implementations should make it possible to use an explicit element for ruby bases, like the rb element in HTML.

§

Ruby implementations should allow annotations to appear on either or both sides of the base text.

8.6 Miscellaneous

§

Line heights must allow for characters that are taller than English.

§

Box sizes must allow for text expansion in translation.

§

Line wrapping should take into account the special rules needed for non-Latin scripts.

Various non-Latin writing systems don't simply wrap text on inter-word spaces. They have additional rules that must be respected. For example

See the CSS Text Level 3 specification for additional background. (This tutorial provides additional examples, if needed.)

§

Avoid specifying presentational tags, such as b for bold, and i for italic.

It is best to avoid presentational markup b, i or u, since it isn't interoperable across writing systems and furthermore may cause unnecessary problems for localisation. In addition, some scripts have native approaches to things such as emphasis, that do not involve, and can be very different from, bolding, italicisation, etc.

In the HTML case, there was a legacy issue, but unless there is one for your specification, the recommendation is that styling be used instead to determine the presentation of the text, and that any markup or tagging should allow for general semantic approaches.

For an explanation of the issues surrounding b and i tags, see Using <b> and <i> elements.

9. Locales, date and time values, and locally affected formats

Expand the following to reveal just the guidelines. Add a check mark to items that are relevant to you. Create a checklist that can be transferred to a GitHub wiki.

Working with time
  • When defining calendar and date systems, be sure to allow for dates prior to the common era, or at least define handling of dates outside the most common range. more
  • When defining time or date data types, ensure that the time zone or relationship to UTC is always defined. more
  • Provide a health warning for conversion of time or date data types that are "floating" to/from incremental types, referring as necessary to the Time Zones WG Note. more
  • Allow for leap seconds in date and time data types. more
  • Use consistent terminology when discussing date and time values. Use 'floating' time for time zone independent values. more
  • Keep separate the definition of time zone from time zone offset. more
  • Use IANA time zone IDs to identify time zones. Do not use offsets or LTO as a proxy for time zone. more
  • Use a separate field to identify time zone. more
  • When defining rules for a "week", allow for culturally specific rules to be applied. more
  • When defining rules for week number of year, allow for culturally specific rules to be applied. more
  • When non-Gregorian calendars are permitted, note that the "month" field can go to 13 (undecimber). more
Working with personal names
  • Check whether you really need to store or access given name and family name separately. more
  • Avoid placing limits on the length of names, or if you do, make allowance for long strings. more
  • Try to avoid using the labels 'first name' and 'last name' in non-localized contexts. more
  • Consider whether it would make sense to have one or more extra fields, in addition to the full name field, where users can provide part(s) of their name that you need to use for a specific purpose. more
  • Allow for users to be asked separately how they would like you be addressed when someone contacts them. more
  • If parts of a person's name are captured separately, ensure that the separate items can capture all relevant information. more
  • Be careful about assumptions built into algorithms that pull out the parts of a name automatically. more
  • Don't assume that a single letter name is an initial. more
  • Don't require that people supply a family name. more
  • ​ Don't forget to allow people to use punctuation such as hyphens, apostrophes, etc. in names. more
  • Don't require names to be entered all in upper case. more
  • Don't normalize the casing in names. more
  • Allow the user to enter a name with spaces. more
  • Don't assume that members of the same family will share the same family name. more
  • It may be better for a form to ask for 'Previous name' rather than 'Maiden name' or 'née'. more
  • You may want to store the name in both Latin and native scripts, in which case you probably need to ask the user to submit their name in both native script and Latin-only form, as separate items. more
  • In standards and standards related documents containing examples that include names of persons, use a variety of names to reflect a global audience. Avoid a bias of names specific to certain regions. more
Designing forms
  • When defining email field validation, allow for EAI (smtputf8) names. more
Working with numbers
  • When parsing user input of numeric values, allow for digit shaping (non-ASCII digits). more
  • When formatting numeric values for display, allow for culturally sensitive display, including the use of non-ASCII digits (digit shaping). more
Localization
  • APIs and protocols SHOULD include language and base direction metadata for all natural language messages and data fields. more
  • All natural language fields or messages, including error messages, defined by a given API or protocol SHOULD be localized into the preferred locale of the user or, if that language is not available, supplied with a suitable fallback or default. more
  • Specifications for APIs or protocols SHOULD define how the user's locale is determined (this is sometimes called language negotiation). more
  • Specifications MAY define a specific default language for messages or errors in an API or protocol. more
  • APIs and protocols SHOULD provide language independent identifiers for errors. more
  • Natural language error message fields, when provided, SHOULD be optional and SHOULD include language and direction metadata. more
  • Natural language error message fields, when provided, SHOULD match the user interface language negotiated for the request when possible. more

9.1 Working with locale-affected values

Software systems that support languages and cultural preferences are said to be internationalized. An internationalized system uses APIs to provide language or culturally specific processing, based on user preferences. These user preferences are usually referred to as a locale. For more information on general internationalization terminology, see Language Tags and Locale Identifiers [LTLI]

§

When definining data formats, use locale-neutral serialization forms.

9.2 Working with time

§

When defining calendar and date systems, be sure to allow for dates prior to the common era, or at least define handling of dates outside the most common range.

§

When defining time or date data types, ensure that the time zone or relationship to UTC is always defined.

§

Provide a health warning for conversion of time or date data types that are "floating" to/from incremental types, referring as necessary to the Time Zones WG Note.

§

Allow for leap seconds in date and time data types.

These occur occasionally when the number of seconds in a minute is allowed to range from 0 to 60 (ie. there are sixty-ONE seconds in that minute).

§

Use consistent terminology when discussing date and time values. Use 'floating' time for time zone independent values.

§

Keep separate the definition of time zone from time zone offset.

§

Use IANA time zone IDs to identify time zones. Do not use offsets or LTO as a proxy for time zone.

§

Use a separate field to identify time zone.

§

When defining rules for a "week", allow for culturally specific rules to be applied.

For example, the weekend is not always Saturday/Sunday; the first day of week is not always Sunday [or Monday or...], etc.

§

When defining rules for week number of year, allow for culturally specific rules to be applied.

§

When non-Gregorian calendars are permitted, note that the "month" field can go to 13 (undecimber).

9.3 Working with personal names

§

Check whether you really need to store or access given name and family name separately.

§

Avoid placing limits on the length of names, or if you do, make allowance for long strings.

§

Try to avoid using the labels 'first name' and 'last name' in non-localized contexts.

§

Consider whether it would make sense to have one or more extra fields, in addition to the full name field, where users can provide part(s) of their name that you need to use for a specific purpose.

§

Allow for users to be asked separately how they would like you be addressed when someone contacts them.

§

If parts of a person's name are captured separately, ensure that the separate items can capture all relevant information.

§

Be careful about assumptions built into algorithms that pull out the parts of a name automatically.

§

Don't assume that a single letter name is an initial.

§

Don't require that people supply a family name.

§

​ Don't forget to allow people to use punctuation such as hyphens, apostrophes, etc. in names.

§

Don't require names to be entered all in upper case.

§

Don't normalize the casing in names.

§

Allow the user to enter a name with spaces.

§

Don't assume that members of the same family will share the same family name.

§

It may be better for a form to ask for 'Previous name' rather than 'Maiden name' or 'née'.

§

You may want to store the name in both Latin and native scripts, in which case you probably need to ask the user to submit their name in both native script and Latin-only form, as separate items.

§

In standards and standards related documents containing examples that include names of persons, use a variety of names to reflect a global audience. Avoid a bias of names specific to certain regions.

9.4 Designing forms

§

When defining email field validation, allow for EAI (smtputf8) names.

9.5 Working with numbers

§

When parsing user input of numeric values, allow for digit shaping (non-ASCII digits).

§

When formatting numeric values for display, allow for culturally sensitive display, including the use of non-ASCII digits (digit shaping).

9.6 Localization

Localization [LTLI] enables users to employ software in the language and locale of their choice. Specifications for protocols and document formats need to consider how to provide the language and formatting that the end-user expects.

Natural language data values need language and base direction in order to ensure proper presentation, even if localized messages are not provided. This includes any error messages or other internal messages that are human readable in an API or protocol. See also [STRING-META].

§

APIs and protocols SHOULD include language and base direction metadata for all natural language messages and data fields.

§

All natural language fields or messages, including error messages, defined by a given API or protocol SHOULD be localized into the preferred locale of the user or, if that language is not available, supplied with a suitable fallback or default.

§

Specifications for APIs or protocols SHOULD define how the user's locale is determined (this is sometimes called language negotiation).

§

Specifications MAY define a specific default language for messages or errors in an API or protocol.

Note

Specifications do not need to require that messages be returned in all possible or all available locales. It is sufficient to make it possible to localize the end-user's customer experience. Implementations can choose which languages or locales to support.

9.6.1 Working with error and exception messages

Protocols, APIs, and document formats sometimes provide a field to pass a human-readable error or exception message from a service to the caller in the form of a string. In general, and as indicated above, any natural language text conveying human-readable messages or human-readable content needs to be associated with language and direction metadata. Where this metadata is missing, the processing or display of the text might be compromised.

Often the intention of the specification author in providing an error or exception message is to convey debugging information to a software developer. Specification authors sometimes assume that error or exception messages are not seen by end users; that software developers will prefer these messages to be unlocalized or appear in a specific language (usually English); or that there are other "practical reasons" why localization of error messages can turn out to be a barrier. For example, there are anecdotes about developers finding it easier to search the Web with the (usually obscure) text of an error because the message itself is insufficiently good at explaining the problem. Searching for this text might produce a result in the developer's preferred language that is more helpful.

Error messages are messages and they are intended for humans, not machines. In many cases, the error message encompasses all of the additional information about what went wrong and, in some cases, the caller is obliged to show the message to the actual end user because there is no other way to convey to the caller about how to fix the problem ("Your credit card has expired"; "The value 10484977 is too large" [oops, forgot the decimal point]; etc.). Localization of these types of messages is actually a good thing and may even be obligatory in some applications.

§

APIs and protocols SHOULD provide language independent identifiers for errors.

For example, HTTP result codes, such as the familiar 404, help users communicate which error they received or look up a translation.

§

Natural language error message fields, when provided, SHOULD be optional and SHOULD include language and direction metadata.

§

Natural language error message fields, when provided, SHOULD match the user interface language negotiated for the request when possible.

A. Revision Log

The following summarises substantive changes since the previous publication, but the material is still subject to significant flux as it develops. This should not be a reason not to use the document. What it so far contains is useful, and any shortfalls can be reported or discussed.

  1. The checklist generator tool was moved to the top of the document.
  2. The table of contents now reports 3 levels of heading.
  3. Lists of links to documents that provide useful background or an overview of a section have been moved to the start of that section. So also have 'see also' links.
  4. Each advisement now carries its own set of links. This makes the links more relevant and more easily noticeable. It also makes it easier to list multiple links, and because the links indicate the target document title, readers do not have to follow the link to know whether they have already read the document pointed to.
  5. Links associated with an advisement are of two types: 'explanations & examples' typically points to a location in another document from which this advisement was lifted, and surrounds it there with explanatory text; 'more' links provide further reading in other documents.
  6. Self-links for each advisement have been changed so that they match the standard style used for headings (§ to the side of the text). This also significantly reduces the complexity of authoring the markup.
  7. Added content in the section on locales, along with text about working with file and path names and working with error messages.
  8. Generally, the markup in the document source has been greatly simplified, making it easier and quicker to maintain the document.

See the github commit log for more details.

B. Acknowledgements

Thanks to Addison Phillips for help reviewing old reviews for recommendations.

Other people who contributed through reviews or issues include Steve Atkin, Andrew Cunningham, Martin Dürst, Asmus Freytag, John Klensin, Tomer Mahlin, Chaals McCathieNevile, Florian Rivoal.

C. References

C.1 Informative references

[CHARMOD-NORM]
Character Model for the World Wide Web: String Matching. Addison Phillips et al. W3C. 11 August 2021. W3C Working Group Note. URL: https://www.w3.org/TR/charmod-norm/
[DOM]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[EPUB-33]
EPUB 3.3. Matt Garrish; Ivan Herman; Dave Cramer. W3C. 4 April 2022. W3C Working Draft. URL: https://www.w3.org/TR/epub-33/
[I18N-GLOSSARY]
Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 11 February 2022. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/
[LTLI]
Language Tags and Locale Identifiers for the World Wide Web. Addison Phillips. W3C. 7 October 2020. W3C Working Draft. URL: https://www.w3.org/TR/ltli/
[RFC6067]
BCP 47 Extension U. M. Davis; A. Phillips; Y. Umaoka. IETF. December 2010. Informational. URL: https://www.rfc-editor.org/rfc/rfc6067
[STRING-META]
Strings on the Web: Language and Direction Metadata. Addison Phillips; Richard Ishida. W3C. 7 March 2022. W3C Working Group Note. URL: https://www.w3.org/TR/string-meta/
[UAX31]
Unicode Identifier and Pattern Syntax. Mark Davis. Unicode Consortium. 26 August 2021. Unicode Standard Annex #31. URL: https://www.unicode.org/reports/tr31/tr31-35.html
[Unicode]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[XML]
Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/