Review of tracker issues for best practices (Part V)

Continuing where I left off...

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

// This has to do with microdata formats and HTML and probably needs a closer look to help resolve this open issue. There are likely to be best practices stemming from the definition of microdata formats stemming from that.

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

BP: Indicate the translatablility or non-translatability of content and spans of content using HTML's translate attribute
BP: For new markup languages that have natural language elements, provide an optional means such as its:translate to indicate whether content should be translated or not

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

BP: when defining an escape syntax for Unicode, clearly and unambiguously specify how supplementary characters are to be encoded. 
BP: If non-BMP characters can be encoded directly, do not support their encoding as a surrogate pair.
BP: to the extent possible, define character escape syntaxes that are consistent with other, similar, ones. For example, JavaScript escapes and Java's escapes are identical (using UTF-16 code units).

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

BP: be careful to specify length limits in terms of code points or code units and use the same semantics in all places.

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

BP: When defining Unicode processing behavior that inconsistent with that recommended by a Unicode technical report or by The Unicode Standard, clearly identify the variation and spell out the reason why such a variation is necessary.
BP: Don't define processing of Unicode that is different from that defined by Unicode.

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

BP: When defining a means of displaying content outside the context of the parent document (such as, for example, showing an "alert" dialog from the context of a Web page), provide a means of conveying the directionality of the calling context.

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

// ime-mode in CSS. Needs more research

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

// bdi vs. isolation

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

BP: when a specification supports different writing modes, provide examples of the different writing modes to help developers remember the implementation details
BP: use writing-mode and directionally neutral identifiers start/end, before/after by default. Optionally provide directionally specific identifiers such as left/right, top/bottom.

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

BP: provide a visible character encoding declaration // this is a repeat, I believe

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

// bidi text examples. I think Richard has already mined these out, but should check

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

BP: when providing directional markup or metadata, provide separate direction values for each text bearing element or field and not just for the document/message/file as a whole.

// stopped at 177

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

Internationalization is not a feature.
It is an architecture.

Received on Thursday, 9 April 2015 20:58:28 UTC