Skip to main content

Translation policy for ICANN

As part of a number of draft management operating principle documents at its San Juan meeting in June 2007, ICANN produced a translation framework.

That document outlined the principles and broad framework for translating documents within the ICANN system, but did not go into real or practical solutions. The purpose of this note is to recognise that translation is an increasingly important issue within the Internet community and so outline the real, practical steps that ICANN is taking with respect to working with other languages.

En Espanol

In arriving at the translation framework, ICANN’s general manager of public participation was charged with: reviewing the recommendation contained within the OneWorldTrust’s review of ICANN; reviewing the documentation referred to within that recommendation; reviewing ICANN’s current translation efforts; and talking to people both within and outside the community in an effort to understand translation efforts put in place by other international organisations.

An internal review document was produced and ran through three iterations over the course of four meetings between March and June 2007. Decisions were taken during a meeting on 15 June 2007 about the best way forward.

The finished internal report suggested the four-layer translation system that is reproduced in the translation framework. Until the translation plan becomes more specific and detailed, ICANN can’t be certain about budget requirements, service levels (i.e. precise timelines) and cost to the community. In the coming fiscal year, ICANN has more than doubled the funds available for translation.

The report made several conclusions and recommendations. They were:


  • The current approach is unsustainable
  • ICANN needs a demand-driven & flexible translation system
  • There needs to be a single system and a single point-of-contact
  • The costs and methods of translation need to be carefully reviewed


  • A four-tier translation stack
  • Introduction of machine translation with wiki-style editing and community-rating
  • Produce a community-request system
  • Hire a consultant with appropriate expertise
  • Review the possibility of an in-house translation team
  • Start on the process immediately

The translation issue is a very complex one and ICANN recognises that it does not have the skills in-house to produce a comprehensive and equitable translation policy.

ICANN will therefore hire someone with the appropriate expertise as soon as possible in order to review the situation and provide a report on how the organisation can move forward as efficiently as possible. Either that report or an interim report will be produced for the Los Angeles meeting at the end of October 2007. That review will include:

  • What ICANN should translate and in which languages
  • What the best system is to provide fast and accurate translations

In the meantime, ICANN has created an internal translation co-ordination committee with members from across the organisation in order to:

  • Identify and hire the expert and prepare the groundwork for his/her review
  • Discover what the level of demand is for different translations
  • Review the different needs and requirements for translation across departments
  • Work out the implications of a broad, systemic translation policy
  • Talk to others outside the organisation, both within the Internet community and those in the wider world, in order to build up awareness throughout ICANN and its community of translation issues

In terms of pragmatic work, the committee will also:

  • Implement machine translation, wiki-style editing and community rating
  • Produce an effective system for registering community interest in particular translations
  • Produce a multi-lingual glossary

ICANN will produce regular updates on its progress on translation here on the ICANN blog and review where and when it can make the most of existing expertise within the Internet community.

This policy (and the other accountability and transparency frameworks and principles) will be discussed in a special session later this afternoon (4pm) at the ICANN meeting in Puerto Rico – click here for more information. Please feel free to comment on both the translation framework and this posting below.


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."