Bp spec bidi

From Internationalization
Jump to: navigation, search

Collaborative editing page

Follow the conventions for editing this page.

Status: Initial Draft ie. please focus on technical content, rather than wordsmithing at this stage.

See the [I18n Core home page].

Author: Richard Ishida

Draft Best Practices for Specification Developers

Handling blocks/chunks of information in source code

Language

  1. It must be possible to indicate the language of the text as a whole.
  2. It should be possible to indicate language for internal blocks of content where the language changes.
  3. Language values should be BCP47 language tags.
  4. In a multilingual environment it must be possible for the user to receive text in the language they prefer. This may depend on implicit user preferences based on the user's system or browser setup, or on user settings explicitly negotiated with the user.

Text direction

  1. It must be possible to indicate the rtl/ltr direction of the content as a whole, ie. set the overall base direction. The default text direction should be LTR.
  2. It must be possible to indicate parts of the text where the base direction changes. This should be achieved using attributes or metadata at a block level, and not rely on Unicode control characters.
  3. 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.
  4. 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.
  5. To indicate the beginning and end of a block of text you should use 'before' and 'after' (maybe block-start/block-end - the terminology is changing), rather than 'top' and 'bottom'.
  6. 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
  1. it should be possible to render text vertically for languages such as Japanese, Chinese, Korean, Mongolian, etc.
  2. vertical text must support line progression from LTR (eg. Mongolian) and RTL (eg. Japanese)
  3. box positioning coordinates must take into account whether the text is horizontal or vertical


Typography

  1. line heights must allow for characters that are taller than English
  2. box sizes must allow for text expansion in translation
  3. ruby text should be supported for CJK text


Handling inline text content in source code

Language

  1. It should be possible to indicate language for spans of inline text where the language changes.
  2. Language values should be BCP47 language tags.

Text direction

  1. 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.
  2. 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.
  3. If users use Unicode control characters, the RLI/LRI/FSI...PDI characters must be supported by the application and recommended (rather than RLE/LRE...PDF) by the spec.
  4. Use of RLM/LRM should be minimised, and expectations of what those controls can and cannot do should be clear in the spec.
  5. To indicate the start/end of a line or paragraph you should use 'start' and 'end' rather than 'left' and 'right'.
  6. 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
  7. allow bidi attributes on all inline elements in markup that contain text
  8. 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 in either of these two scenarios.
  9. declare the default base direction of the document to be LTR.
  10. make it possible to set the base direction on the top level element in a document
  11. ensure that the base direction set on an element is applied to all contained elements and text (unless, of course, the base direction is changed by a contained element using the directional attributes)
  12. provide a span-like element that can be used for any text content to change the base direction in the absence of other markup
  13. avoid natural language text in elements that only allow for plain text and in attribute values.


Identifiers and source code

Case distinctions

  1. identifiers should be case-sensitive