In this video, we’ll share some of the Internationalization Working Group’s latest work:.

Internationalization is often invisible when it works. But when it does not, people notice immediately. Our work is about preventing those failures through the architecture of the Web itself.


One area we are exploring is Message Resources: a standard container for messages written using Unicode MessageFormat 2.

A message is rarely just a string. Translators may need comments explaining where it appears. Tools may add metadata. Messages may span multiple lines or contain several related parts.

Existing localization formats solve different pieces of this problem. But no single format addresses all the identified needs while remaining easy for people to author in a text editor.

Our draft explainer examines a human-friendly syntax, a common data model, and a vocabulary for properties and metadata. The intention is to complement existing localization ecosystems.

This work could also provide a foundation for future DOM localization, helping localized messages connect more reliably with the structure and content of the Web.



Another major focus has been ruby.

Ruby is widely used in East Asian content for pronunciation, meaning, and other information. Real-world ruby can be complex.



We published the HTML Ruby Extensions specification to promote and guide implementations of a revised and extended model for ruby, one that more completely addresses the needs of ruby on the Web platform.

An important part of that work is bringing back the `rb` element, which was previously made obsolete in HTML. The `rb` element explicitly identifies ruby base units, giving implementations clearer structural information for richer typography and more reliable processing.



Visual rendering is only part of the challenge. What should happen when content containing ruby is read aloud?

Reading both the base and the annotation can cause distracting repetition, or even change the apparent meaning. Reading only the annotation can lose information about tone or pitch accent. And reading only the base may produce the wrong pronunciation.

To investigate these issues, we published *Text-to-Speech Rendering of Electronic Documents Containing Ruby: User Requirements*. We also call it ruby-tts-req.

Its central lesson is that correct speech output may require several sources of information at once.



Specifications are essential, but they are not enough.

We updated many of our articles, language-enablement documents, and our guidance for specification developers. We also added many translations to our articles.

To make this growing body of material more dependable, we added numerous automated checks to our articles. These checks help us detect potential issues early and improve the consistency of markup, links, metadata, and document structure.

We are also investing in ways to make internationalization knowledge easier to learn and share.

We published a video about character encoding, and there are more videos in production about our language-enablement initiative.



Thank you.