Review of tracker issues for best practices (part II)

Picking up where I left off...

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

BP: formats that allow insertion of text or elements inline should supply bidi isolation
// probably we need a whole series of BPs about isolation

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

BP: Specifications should require user agents to implement the Unicode spec re Default Ignorable Code Points (Unicode Standard version 5.2, Chapter 5 (http://unicode.org/versions/Unicode5.2.0/ch05.pdf), section 5.21), including never displaying the directional formatting characters (LRM, RLM, LRE, RLE, LRO, RLO, and PDF) inappropriately (e.g. as empty boxes or advance widths) even if the underlying platform does not handle them properly. In particular, this must be the case for script dialog text, page titles, and tooltips.

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

BP: elements (such as title) intended for display outside the context of the document as a whole must provide a direction attribute (and a language attribute) to help ensure proper display

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

BP: attributes that are intended for natural language text should provide a means of indicting the direction of the text. Example, provide "altdir" for "alt"

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

BP: elements that might be rendered by native controls (such as combo box items) should have a health warning indicating the need to apply or pass language and direction attributes to the native renderer.
BP: elements that might be rendered by native controls should be rendered according to the direction (set or inherited) for that element

http://www.w3.org/International/track/issues/51
BP: On an OS that has a widespread UI convention for setting direction, user agent should support it on input and textarea elements
// this one should be survey further

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

BP: When an input value is remembered, its direction should be remembered too

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

http://www.w3.org/International/track/issues/55 
Positioning of visual elements such as scroll bars based on top-level direction
// needs more investigation

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

BP: Specifications that display text out of context that do not pass direction should use "auto" directionality. The example given is JavaScript's alert()

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

BP: When an XML grammar allows UTF-16 as an encoding, the BOM is required (per XMLSpec http://www.w3.org/TR/REC-xml/#charencoding)

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

http://www.w3.org/International/track/issues/60 
BP: In document character encoding declarations are always useful, even when non-functional
// this is to some degree a repeat from issue-22's BP

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

// the UTF-8 BOM: encouraged or discouraged?

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

http://www.w3.org/International/track/issues/65 
BP: define whether case sensitivity applies in search/find mechanisms
// case insensitivity only for ASCII values
// best practices here should be taken from Charmod-Norm's section on ACI/UCI/ACS
// http://www.w3.org/Bugs/Public/show_bug.cgi?id=10153


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

BP: use hexadecimal entities in preference to decimal ones in examples

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

// requirements for a "find" type operation should be taken from (and/or incorporated into) Charmod-Norm's section on searching
// this item is about normalization sensitivity of a find operation

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

BP: data structures that support sorting of natural language text for user presentation should provide a means to store a separate "pronunciation" field, since this is necessary for languages like Chinese and Japanese and cannot be computed with high accuracy.

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

http://www.w3.org/International/track/issues/71 
BP: data structures for personal names must be able to support different numbers of name tokens, different ordering of name tokens, and different uses.
// issue 70 is multiple family names, 71 is culturally linked name positioning

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

BP: do not make lang case-sensitive; do not make language tag matching case sensitive
// note that language tag matching/processing is supposed to be case insensitive per BCP 47

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

// preferred names for encodings: probably we should reference Encoding

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

BP: when creating a "spell check" feature (or other natural language processing feature) for user input text, it should be possible for the content author to indicate that a field should not be checked. 
// side thought: should we also BP the use of ITS for things like indicating DNT?

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

http://www.w3.org/International/track/issues/80 
BP: when defining automatic quote generation, the enclosing text's language should be used to form/shape the quote marks (?)
// this is the infamous <q> issue

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

// this has to do with, when stripping CR and LF line terminators, whether other terminating characters should also be stripped. We decided not to. Should we document this somewhere?

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

BP: when a namespace uses ASCII case insensitivity, values in that namespace should be limited to ASCII
// counter examples exist (CSS: I'm looking at you!) and they suck

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

BP: when the Gregorian calendar is specifically used, a health warning should be included reminding of the existence of other calendars
// note Ian's health warning in HTML5

===


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

Internationalization is not a feature.
It is an architecture.

Received on Saturday, 28 March 2015 20:29:54 UTC