Get involved with Language Enablement

How to participate

You can engage with the language enablement work on various levels, depending on your availability.

To get started, or if you want a low level of commitment, get involved as an List subscriber. This involves simply subscribing to a mailing list and providing occasional insights on the group's GitHub discussion threads. Follow the link for more details.

How to sign up:

1. Find the group(s) you are interested in – there's a list of group home pages in the right column of this page. For an overview of all work, with links to GitHub repositories, mailing lists, etc, see the list of groups.
2. Take a look at the home page and the issue list, and check the code of conduct, contributing, and licence information.
3. While on the home page, check out the "Help Wanted!" links. These point to typography questions that we hope experts will help us answer.
4. Click on the subscribe link and join the mailing list to set up notifications. You will receive a maximum of one email a day (per group) that has a link to relevant GitHub threads that have received comments or been created.
5. Get a GitHub id, so that you can participate in the discussions (really easy, and not privacy invasive).
6. Add comments to the GitHub issues, or create your own issue(s) if you know of a gap in Web support.

We use the word 'group' to refer to an area of activity. In some cases there is a constituted task force, where people hold meetings and organise themselves. In other cases, this is a group of email subscribers focused on a particular region or script, and managed through a GitHub repository.

If you have the time and inclination to get involved on a more regular basis, consider joining the group as a Participant. Participants follow the GitHub activity closely, look for opportunities to provide feedback and suggestions, and attend teleconferences/meetings where possible. They may also contribute text for documents.

We also welcome applications to take a more active role in the group by taking on responsibility for producing work as an Editor and/or (Co-)chair.

To contribute in these ways, contact the W3C staff contact.

Goals of a language enablement group

• Constitute an expert network that the W3C can turn to if they have questions about internationalization of their technologies, or that can raise issues and requirements related to Web technologies.
• Investigate and document situations where people trying to use the Web encounter obstacles for using their own language and writing system. This work should consider whether current standards and implementations provide, or promise support for, the problematic features, and should demonstrate the issues using tests or examples.
• Provide a set of requirements for missing features, or in some cases describe more fully how the language/script should work. This is done in a technology agnostic way.
• Raise bugs and change requests against specifications and applications to encourage support for the features that end users are missing.

How things work

Github discussions

It's really easy for non-technical people to use GitHub issues for discussion.

All technical discussion should take place in GitHub issues, and not on the mailing lists, since they help us manage conversations. Here's an example of a discussion list for the Southeast Asian group.

It's ok to use languages other than English in a GitHub thread, but important information should eventually be summarised in English for the benefit of those who don't speak the language.

Those new to GitHub may wish to read a short introduction: Working with GitHub issues.

Describing gaps

The key deliverable of an lreq group is one or more gap-analysis documents. See the Japanese gap-analysis document, for example.

These documents use a standardised set of headings down to the 3rd level, and then the detailed content is added topic by topic. There is a set of ideas at the beginning of each section, in italics, to suggest things to cover in each section.

The detailed content of the gap-analysis document is produced using GitHub issues, rather than by editing the HTML. See an example topic for Japanese gap-analysis. The text of the initial comment in an issue is automatically inserted into the HTML document framework. The comment fields lower down the GitHub thread can be used to discuss the current text and/or provide alternative content.

For details about how to produce a new gap-analysis document, see How to contribute to a gap-analysis document.

The gap-analysis document aims to describe issues and the current state of implementation in specifications or browsers. It's not meant to describe the actual requirements – that is done in a separate document that is technology agnostic. These requirements documents can range from the very large Japanese Layout Requirements, to small documents that only provide the essential information needed to support the issues raised in the gap-analysis document, such as the Khmer Layout Requirements. These documents are written in HTML.

Tests

An important part of gap-analysis work involves exploring what features are supported and creating tests that can be used to communicate current behaviour to others.

The framework we use for our language enablement groups provides a way to quickly create tests and tweak them to explore browser support. For more information about how to create these tests, see Writing i18n tests, and follow the link to the description of Interactive exploratory tests.

More information

For more information about the language enablement framework that groups use, and useful resources that span the work of all the groups, follow the links on the page Language enablement.

Contacts

• Fuqiao Xue (xfq @ w3.org), Internationalization Lead, Internationalization Working Group Staff Contact
• Richard Ishida (ishida @ w3.org), Internationalization Specialist
• Addison Phillips (addisoni18n @ gmail.com), Internationalization Working Group Chair
• Martin Dürst (duerst @ it.aoyama.ac.jp), Internationalization Interest Group Chair