Request a review

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

How to ask for a review

Please raise a GitHub issue. Requesting a review that way creates a request that can be efficiently pushed through the pipeline in our review radar.

If you want to limit the visibility of your request for some reason, you could send an email to member-i18n-core.

Please do not send a request directly to the Chair or Staff Contact.

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 that issues will arise.

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 do a self-review at the time you publish a First Public Working draft. The short self-review form helps you identify aspects of your spec that will need attention, and points to a more detailed checklist for things that are relevant.

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.

The aim at this stage is not so much to spot things that are problematic, but rather to help you take on board the things you'll need to consider as you go forward.

Firming-up review

The current W3C process removes the Last Call step and encourages working groups to seek wide review much earlier in the spec development process, so that there is time to address any necessary changes in a timely fashion and with the least nonconformance cost. The aim is to avoid the last minute crush that Last Call used to produce, once the Working Group was tired and ready to move on to the next phase.

Do not expect to be able to turn around an internationalization review in less than a month. In fact, normally you should start the review process at least 2-3 months before CR. This is because of factors such as the following:

  1. the i18n WG needs to schedule resources for the review, taking into account the other work it has in hand.
  2. the reviewers need time to become familiar with your specification, and probably also with the overall technology, before they can start the review.
  3. the review work itself is not quick, and requires discussion during weekly i18n teleconferences, but the time it takes is relatively short compared to the time needed to report, discuss, and implement any issues arising from 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.

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

Doing a self-review

The best place to start the horizontal review process is with the Short i18n review checklist. This helps you identify aspects of your spec that need internationalization attention, describes what you need to consider, and points you to more detailed checklists to use for a self-review.

In the detailed checklists 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 creating a report a GitHub repository (like this). Do so in your own repository, so that your group can follow any resulting discussion. The self-review page allows you to copy starter text (see the Useful Links in the right column). Copy the text to a comment field in a GitHub issue in your repo, and then annotate it. Add an i18n-tracker label when you create your issue, to alert the Internationalization WG. If you want us to check it, raise an i18n-request issue.

Note that the checklists are still in development. We are likely to add to them 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.

Using i18n github labels in your repo

All W3C Working Group repositories have labels to enable us to track internationalization related topics. There are two main types of label, and they should be already set up for your repo:

  1. i18n-tracker provides a way for you to attract the attention of the i18n WG to a discussion in your issue list. We also use it to indicate a discussion that we are interested in following, although it was not raised as part of review feedback. We don't require an agreed resolution to these issues before a transition. Anyone can set this label against an issue in their own repo, and when they do the i18n WG will be automatically notified.
  2. i18n-needs-resolution signals an issue where the i18n WG has 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. Your WG should check that the i18n WG is satisfied with any issue marked with this label before you proceed to your transition. This should only be set or removed by the i18n WG.

After one of these labels is applied to an issue, notifications are automatically sent to the i18n WG members as the thread develops.

The i18n WG may convert a tracker label to a needs-resolution label, if they consider the issue to be important.

The i18n WG may also set up additional labels that notify groups of linguistic experts about issues that are relevant to them. For example, i18n-alreq sends notifications to the Arabic Layout task force members each time a comment is added to an issue.