Review of tracker issues for best practices (Part IV)

Continuing from where I left off...

http://www.w3.org/International/track/issues/105

BP: When matching strings (such as attribute values), use case-sensitive matching
BP: When matching strings case-insensitively, use canonical caseless matching, not compatibility caseless matching

http://www.w3.org/International/track/issues/106

BP: When processing query strings in URIs and applying the character encoding of the host document, supply a health warning about the handling of characters not in that character encoding.
// probably more BPs here related to encoding in query

http://www.w3.org/International/track/issues/107

BP: when specifying the handling of unencodable sequences, specify that the character encoding's replacement character should be used. For example, in Unicode this is U+FFFD. In Latin-1 this is ? (0x3F). In some other encodings is may be another character.

http://www.w3.org/International/track/issues/108

BP: When referring to character encodings, do not use the term "encoding", as this can be confused with other types of encoding, such as transfer encoding

http://www.w3.org/International/track/issues/111

// this issue is about the date/time format used in html lastModified being MM/DD/YYYY hh:mm:ss

http://www.w3.org/International/track/issues/116

BP: APIs should provide a way to obtain the direction of element, attribute, or text values

http://www.w3.org/International/track/issues/118

BP: when the language of a text value is set to the empty string, this should be taken to mean that the language of the value is explicitly unknown (??)
BP: when the language of a text value is explicitly unknown, implementations should be permitted to apply appropriate processing

http://www.w3.org/International/track/issues/122

BP: when describing bidirectional processing, an informative or normative reference to UAX9 (UBA) should be provided
http://www.unicode.org/reports/tr9/


http://www.w3.org/International/track/issues/123

BP: for markup grammars that provide their own directionality, Unicode bidirectional controls should be restricted so that any embedding or overrides generated by these characters do not start and end with different parent elements, and so that all such embeddings and overrides are treated as if the character U+202C were inserted at that point.

http://www.w3.org/International/track/issues/124

BP: when a markup grammar includes bidirectional markup, the document's bidirectional markup (such as HTML's @dir) should be normatively preferred to Unicode bidi control characters and the need for document authors to manually control directionality.

http://www.w3.org/International/track/issues/126

BP: for document formats that allow for a document wide language declaration, there should be a health warning that this information should be supplied. (??)
BP: ditto for direction

http://www.w3.org/International/track/issues/129

// do not override Content-Language ?

http://www.w3.org/International/track/issues/130

BP: when defining a document format that can use legacy character encodings, a file-internal character encoding declaration must be supplied
BP: define UTF-8 as the preferred encoding for any document format
BP: for new document formats, define UTF-8 as the only accepted character encoding

http://www.w3.org/International/track/issues/133

// <pre> handling for newlines for Unicode bidi and references to the CSS. Needs more investigation

http://www.w3.org/International/track/issues/135

BP: when defining list styles, refer explicitly to CSS and to our WG note
// note: should we reexamine the WONTFIX on this issue? Potentially some text should be included even if the attribute values don't change

http://www.w3.org/International/track/issues/136

BP: the internal storage format for numeric values should be locale-neutral even if the display or input of the value is not.
BP: numeric values should be formatted for display and accepted for input from users in a locale-sensitive manner
BP: the locale used for display/formatting of numbers should be controllable by the content author using language attributes

http://www.w3.org/International/track/issues/139

http://www.w3.org/International/track/issues/140 
// multilingual <q> nesting again, someone should spend time to extract what we've learned

http://www.w3.org/International/track/issues/142

// complex ruby support



Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Received on Tuesday, 31 March 2015 16:14:26 UTC