Category: w3cWebArchitecture

The article Can we derive base direction from language? is out for wide review. We are looking for comments by Thursday 1 April.

Sometimes people wonder whether it’s possible to obtain a definitive list of language tags which indicate a RTL base direction, so that there would be no need for separate direction metadata. This article looks into whether that is really feasible. (Spoiler: The W3C Internationalization Working Group believes it is not a feasible approach.)

Please send any comments as github issues by clicking on this link, or on “Leave a comment” at the bottom of the article. (This will add some useful information to your comment.)

CSS defines the typographic character unit as a basic unit of text for use with editing operations, however the meaning of that term can vary according to the operation, and there are issues in working with such units in complex scripts. In this article we look at examples of some of those differences and issues.

Read the article.

The article Use cases for bidi and language metadata on the Web is out for wide review. We are looking for comments by Thursday 11 March.

The W3C Internationalisation Working Group recommends that data formats and string data are always associated with information about text direction and language. This is to ensure that the data can be correctly managed when displayed to a user. This article explores use cases that substantiate the need for this type of information.

Please send any comments as github issues by clicking on this link, or on “Leave a comment” at the bottom of the article. (This will add some useful information to your comment.)

The article Typographic character units in complex scripts is out for wide review. We are looking for comments by Thurday 25 February.

CSS defines the typographic character unit as a basic unit of text for use with editing operations, however the meaning of a that term can vary according to the operation, and there are issues in working with such units in complex scripts. In this article we look at examples of some of those differences and issues.

Please send any comments as github issues by clicking on this link, or on “Leave a comment” at the bottom of the article. (This will add some useful information to your comment.)

In preparation for publication as a Working Group Note, we are seeking wide review of the document Rules for Simple Placement of Japanese Ruby. We are looking for comments by Friday 26 July.

The Japanese layout requirements document describes some complex aspects of ruby handling, and frequently offers alternative possible approaches. This document provides a single, simple set of rules for placement of Ruby text in Japanese typography which can be used as a minimal baseline by implementers and spec developers.

Please send any comments as github issues.

The Internationalization Working Group has published a First Public Working Draft of Rules for Simple Placement of Japanese Ruby. This document provides a simple set of rules for placement of ruby text in Japanese typography that can be used as a minimum baseline for implementers and specification writers. It was developed by the JLReq (Japanese Layout) Task Force as a companion to Requirements for Japanese Text Layout 日本語組版処理の要件（日本語版）.

Ruby is the name given to the small annotations in Japanese content that are rendered alongside base text, usually to provide a pronunciation guide, but sometimes to provide other information.

A First Public Working Draft of Strings on the Web: Language and Direction Metadata was published.

This document describes practices for identifying language and base direction for strings used on the Web. It was developed as a result of observations by the Internationalization Working Group over a series of specification reviews related to formats based on JSON, WebIDL, and other non-markup data languages. Unlike markup formats, such as XML, these data languages generally do not provide extensible attributes and were not conceived with built-in language or direction metadata.

The concepts in this document are applicable any time strings are used on the Web, either as part of a formalised data structure, but also where they simply originate from JavaScript scripting or any stored list of strings.

Public comments are welcome, please raise them as github issues.

The Short i18n review checklist points developers of specifications to various aspects of a spec that may need internationalization review. It can also be used by spec reviewers, to get an idea of what to look for in a spec.

Only 12 items long, it follows the format: if the spec or its implementation does X then check Y, and points to the relevant parts of the detailed checklist for more information.

It’s not exhaustive, but it hits the main topics that regularly arise when spec developers are wondering whether their spec may have internationalization issues. If you have comments or questions, please use the GitHub issue list.

The Internationalization Working Group at the W3C has published a new Working Group Note. Character Model for the World Wide Web: String Matching provides authors of specifications, software developers, and content developers a common reference on string identity matching on the World Wide Web and thereby increase interoperability.

String identity matching is the process by which a specification or implementation defines whether two string values are the same or different from one another. It describes the ways in which texts that are semantically equivalent can be encoded differently and the impact this has on matching operations important to formal languages. Topics include normalization and case folding.

Types of language declaration describes how ‘metadata’ and ‘text-processing’ language declarations differ.

HTTP headers, meta elements and language information has been updated to read better, and the information that was to become the previously mentioned article was removed.