Request a review

This page describes how to contact the W3C Internationalization Working Group to get a review of your specification or document.

When to ask for a review

A review of a spec is just the starting point for what can be a fairly long process of discussion, negotiation and accommodation. If you expect to go to Candidate Rec just a week or so after your review period ends, you are likely to have problems keeping to your schedule if controversial issues arise during review – and unless you have done adequate review work beforehand, it is quite possible.

Please also bear in mind that the i18n WG may already have other reviews and work in progress that they have to fit around your schedule, so the longer you can give them to review and discuss your spec the better.

The earlier you can involve the i18n WG the better, since it gives more time for discussion, to help everyone understand the issues at hand, and to think through an alternative approach, and reduces the need for rework.

First Public Working Draft

We recommend that you alert the i18n WG when you publish a First Public Working Draft and request an initial review if there are likely to be internationalization-affected features in your spec. These include, but are not limited to:

  1. character encoding choices
  2. normalization of characters, white-space, etc.
  3. case conversion questions
  4. natural language text in multiple languages
  5. natural language text that may be exposed in a right-to-left script
  6. time and date related features
  7. personal names or street addresses
  8. typographic support that may involve different conventions in non-Latin scripts (from line-breaking and justification, to font support and ruby text)
  9. etc.

FPWD is indeed early, since your spec is still far from mature, but the sooner potential issues are pointed out or attention is drawn to areas that will need careful attention, the more time is available for discussion and reformulation, where necessary, and the lower the non-conformance cost.

Self review

We also recommend that you organise an internal review. This can be done before FPWD or other review requests are sent. Spotting potential issues early on should result in fewer nasty surprises, and should reduce the work needed in review and post-review discussion. It's better to prevent than to have to correct.

You can find a checklist by following this link. The information is grouped by topic, then by task. For each task you will find links to relevant information and also a checklist you can use for the review.

We recommend that you go through the self-review checklist at appropriate points during the development of your spec, and before requesting reviews. You may want to assign a specific person with the responsibility to monitor the i18n implications of your spec work and discussions. That person doesn't need to know the answers, just ensure that the checklist is considered and contact the i18n WG when advice is needed.

Note that the self-review checklist is still in development. We are likely to add to it on an ongoing basis. There may be parts that you disagree with, or that you don't understand – if so, please let us know. Using the checklist may also prompt you to think of things you should consider that are not yet covered in the checklist.

Firming-up review

The new W3C process removed the Last Call step in order to avoid the last minute crush that Last Call used to produce, once the Working Group was tired and expecting that it was ready to move on to the next phase. The idea is that you should be able to find other ways to review, and get input earlier in the process.

As you will have gathered, the i18n WG strongly supports this approach, and we would ask you to schedule a second review of your spec well before the transition to CR.

You can also ask us for advice on an adhoc basis, and we'll try to help.

How to ask for a review

We would normally ask you to send an email requesting a review to This is the i18n IG list, where we try to conduct our technical discussions. There are over 300 people on the list, so it's possible that other people than those on the i18n WG will look at your spec.

If you want to limit the visibility of your request for some reason, you could also use either public-i18n-core (which is mainly restricted to WG members) or member-i18n-core.

Sending to a group list is strongly preferred rather than sending a request to the Chair or Staff Contact.

Using i18n github labels in your repo

The i18n WG has begun adding labels to the issue lists of other Working Groups, so that we can track internationalization related topics. There are two types of label:

  1. i18n-comment signals an issue where we have raised a comment against a spec, or where we support such a comment raised by someone else, and we want to be satisfied with the resolution.
  2. i18n-tracking indicates a discussion that we are interested in following, although it was not raised as part of review feedback.

When one of these labels is added to an issue, notifications are sent to the i18n mailing lists as the thread develops.

Use of the i18n-tracking labels can help us intercept, track and contribute to resolving potential issues at an early stage. Sometimes i18n people apply the label while looking at your issue list, but we can't scan everything so we rely on you to also apply this label to i18n issues we haven't noticed.

If you would like to set up such a label, and the associated notifications, please send a note to We are happy to do the setup for you.