To support local relevance of Web pages and eBook formats we need more local experts to help gather information, to review decisions, and to lobby or support via coding the implementation of local features in browsers and ereaders. If you are one of these people, or know some, please get in touch! The rest of this page will tell you how.
How to participate
To get started, or if you want a low level of commitment, get involved as a Follower. This involves simply subscribing to a mailing list and providing occasional insights on the group's GitHub discussion threads.
How to sign up:
- Look at the list of groups and find the group(s) you are interested in.
- Take a look at the GitHub home page and the issue list, and check the code of conduct, contributing, and licence information.
- 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.
- Get a GitHub id, so that you can participate in the discussions (really easy, and not privacy invasive).
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.
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.
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.
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