Review of tracker issues for best practices

All,

I have started to review all of the issues in our tracker for potential best practices ("BP") items to include into our guidelines for specification writers. The BP text here is not a fully-fleshed proposal per-se. Missing issues did not contain something actionable in my view. The last current issue number in the modern tracker is 436, so I've completed the first 10% of the survey.

Addison

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


Here are results so far:

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

BP: do not create your own lang attribute for XML formats. Use existing @lang.

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

BP: reference BCP 47 for language tags
BP: reference BCP 47 for language tag matching
BP: be specific about the form of language tags you expect. The word "valid" has special meaning in BCP 47. Generally "well-formed" is a better choice. 

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

BP: In the schema description, various items that contain human readable text are stored as attribute values. We normally recommend that you don't do this (see http://www.w3.org/TR/xml-i18n-bp/#DevAttributes) because of potential translation and annotation difficulties (eg. markup of bidi text). In several cases these attributes are the only content on empty elements.

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

BP: for any natural language text elements, provide a localization mechanism that allows for in-language presentation of the item
Example: A Japanese font vendor would probably want a Japanese audience to see its name in kanji, but present a Latin transcription to non-Japanese viewers. To enable this, the localised version access mechanism (ie. use of the text element) should also apply to the content of the vendor element.

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

BP: provide inline markup, most especially a <span> type element for flowing or paragraph-organized text.

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

BP: provide a direction attribute for all natural language text elements

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

"The automatic removal of OpenType features such as GPOS and GSUB information at any stage in the process of deploying a WOFF file is strongly discouraged. Many writing systems around the world rely on these features for very basic display of text in the script that they use."

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

BP: when writing specs that show examples of mixed direction text, use UPPER CASE FOR RTL and lower case for LTR in ASCII-examples. E.g. "SDROW EMOS ERA EREH

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

BP: do not isolate bidi on line break; use paragraph separators to reset the bidi algorithm
Comment: is this comment obsolete?

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

BP: Use proper U+XXXX syntax to represent Unicode code points. 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.

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

Needs further investigation as to whether there is a BP here.

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

Needs further investigation. This one has to do with recommendations regarding character rotation in vertical formats.

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

BP: do not assume that the positioning of text decoration, such as underlines or bouten marks will follow your expectations from some other language (???)

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

Needs further investigation as to whether there is a BP here. Extensive text in this issue suggests there is one.

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

BP: Allow in-file encoding declarations, even when they are superfluous. For example, allow <meta charset=utf-16> even though the BOM and byte-sniffing will already have determined the encoding long before this tag is read. This allows files to be self-documenting and encourages content authors to write the encoding down in the file consistently and not just as a special case.

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

this became part of issue-88. HTML's resolution of this issue may not override the need for a BP related to content language (target audience) declaration in other specifications.

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

BP: use (allow) and prefer markup in a document format for bidirectionality to the use of document-external styling

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

this and other comments related to bidi isolation and bidi direction auto detection probably need to be examined for BP

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

BP: Provide a means to send the direction (either detected from the content or supplied by the document) with any natural language text submitted in forms to the server.

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

Needs further investigation as to whether there is a BP here. Has to do with bidibreak.

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

BP: U+2028 and U+2029 should affect UBA processing

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

BP: In elements where line breaks are not collapsed, e.g. <textarea> and elements with white-space:pre|pre-line|pre-wrap, line breaks should constitute UBA paragraph breaks.

http://www.w3.org/International/track/issues/42 
BP: Line breaks in the plain text displayed by the page's scripts using functions such as Javascript's alert() and confirm() should constitute UBA paragraph breaks.


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

Internationalization is not a feature.
It is an architecture.

Received on Wednesday, 25 March 2015 21:51:09 UTC