Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I18n checklist: text direction #126

Open
13 of 19 tasks
fsteeg opened this issue May 9, 2023 · 0 comments
Open
13 of 19 tasks

I18n checklist: text direction #126

fsteeg opened this issue May 9, 2023 · 0 comments

Comments

@fsteeg
Copy link
Member

fsteeg commented May 9, 2023

This is a self-review checklist based on the Internationalization Best Practices for Spec Developers.

(I've skipped what seemed formatting and markup related here.)

See also issue #52, #125 and notes at https://etherpad.lobid.org/p/reconciliation-i18n.

Basic requirements

  1. It must be possible to indicate base direction for each individual paragraph-level item of natural language text that will be read by someone. more
    Comments_go_here
  2. It must be possible to indicate base direction changes for embedded runs of inline bidirectional text for all localizable text. more
    Comments_go_here

Background information

  1. Do not assume that direction can be determined from language information. more
    Comments_go_here

Base direction values

  1. Values for the default base direction should include left-to-right, right-to-left, and auto. more
    Comments_go_here

Handling direction in markup

  1. The spec should indicate how to define a default base direction for the resource as a whole, ie. set the overall base direction. more
    Comments_go_here
  2. The default base direction, in the absence of other information, should be LTR. more
    Comments_go_here
  3. The content author must be able to indicate parts of the text where the base direction changes. At the block level, this should be achieved using attributes or metadata, and should not rely on Unicode control characters. more
    Comments_go_here
  4. 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. more
    Comments_go_here
  5. 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. more
    Comments_go_here

Handling base direction for strings

  1. Provide metadata constructs that can be used to indicate the base direction of any natural language string. more
    Comments_go_here
  2. Specify that consumers of strings should use heuristics, preferably based on the Unicode Standard first-strong algorithm, to detect the base direction of a string except where metadata is provided. more
    Doesn't this conflict with the point above: The default base direction, in the absence of other information, should be LTR.
  3. Where possible, define a field to indicate the default direction for all strings in a given resource or document. more
    Comments_go_here
  4. Do NOT assume that a creating a document-level default without the ability to change direction for any string is sufficient. more
    Comments_go_here
  5. If metadata is not available due to legacy implementations and cannot otherwise be provided, specifications MAY allow a base direction to be interpolated from available language metadata. more
    Doesn't this conflict with the point above: The default base direction, in the absence of other information, should be LTR.
  6. Specifications MUST NOT require the production or use of paired bidi controls. more
    Comments_go_here

Setting base direction for inline or substring text

  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. more
    Comments_go_here
  2. It must be possible to also set the direction for a span of inline text to auto, which 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. more
    Comments_go_here
  3. If users use Unicode bidirectional control characters, the isolating RLI/LRI/FSI with PDI characters must be supported by the application and recommended (rather than RLE/LRE with PDF) by the spec. more
    Comments_go_here
  4. Use of RLM/LRM should be appropriate, and expectations of what those controls can and cannot do should be clear in the spec. more
    Comments_go_here

Detecting & matching direction (TBD)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant