At-Large Translation and Transliteration of Contact Information PDP Initial Report Workspace
Comment Close Date | Statement Name | Status | Assignee(s) | Call for Comments Open | Call for Comments Close | Vote Announcement | Vote Open | Vote Reminder | Vote Close | Date of Submission | Staff Contact and Email | Statement Number |
---|---|---|---|---|---|---|---|---|---|---|---|---|
11.01.2015 | Translation and Transliteration of Contact Information PDP Initial Report | ADOPTED 13Y, 0N, 0A | satish.babu | 14.01.2015 | 20.01.2015 23:59 UTC | 23.01.2015 23:59 UTC | 23.01.2015 23:59 UTC | 29.01.2015 | 30.01.2015 23:59 UTC | 31.01.2015 | Julie Hedlund Lars Hoffmann Policy-staff@icann.org | AL-ALAC-ST-0115-02-00-EN |
FINAL VERSION TO BE SUBMITTED IF RATIFIED
Please click here to download a copy of the pdf below.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
A.1 ALAC commends the Translation and Transliteration of Contact Information PDP Working Group for the work done so far on this important area.
A.2 ALAC considers that Contact Information such as Whois forms an important part of metadata that drives the Internet, and may be of interest to many classes of users including end-users and law-enforcement.
A.3 ALAC feels that transparent access to this information, in a form that can be readily used by end-users, is an important factor that enhances end-user trust and confidence in the Internet.
A.4 ALAC recognizes that in the interests of diversity, Registrants should be allowed to provide Whois information in their own languages and scripts. However, in the interests of the rest of the end-users on the global Internet, ALAC considers that it would be desirable to transliterate and/or translate ('transform') the information provided in non-English languages/scripts to English/Roman.
A.5 If there is no requirement that registration information be also provided in English, it is conceivable that some registrants may attempt to limit transparent access to their Whois information by using relatively obscure scripts and languages for submitting registration information.
A.6 The report points to several potential impediments to making available transformed information, including: (a) difficulty in accurate translations and unavailability of exactly equivalent phrases in English; (b) lack of automated tools for good-quality translations; (c) financial burden of translation; (d) difficulties in re-translating in case of changes to the information provided; (e) the large number of domains, the very large volume of information, and the consequent difficulty in validation of translation; (f) inherent unfairness to information-providers as they may be unable to parse/understand the translated content; and (g) lack of transformation standards that may result in multiple valid but incompatible transformations.
A.7 However, considering increased globalized use of the Internet around the world, it is likely that some of these issues may not pose difficulties in the intermediate term. At this time, English remains the most widespread link language used by diverse communities to understand each other. Many or most registrants are likely to use English as a second language at least, since many technical aspects of the domain hosting require its use (e.g. configuring servers using Linux or Window, programming web sites, accessing technical documentation, using credit cards). Further, automated transformation tools do exist for languages used by some of the very large communities (such as Chinese & Hindi).
A.8 Whereas having registration information in English is desired, several impediments make mandatory translations infeasible (whether by registrants or registrars).
Considering the above, ALAC would like to recommend the following.
Recommendations
B.1 As proposed in the Preliminary Recommendation #1, transformation of contact information does not have to be mandatory. However, there should be a provision for it to be maintained in two forms: a mandatory 'canonical' form in the original language, and an optional 'transformed' form after transliteration/translation. The latter should be a close approximation to the original that can be parsed, understood and used by other communities.
B.2 All ICANN databases, forms and documents should provide for capturing, displaying, storing and maintaining both the forms.
B.3 Registrars should provide Registrants with the option of entering both forms while creating new entries or editing existing entries.
B.4 In the intermediate term, transformation & validation of contact information should be taken up through collaborative efforts of Registrars and the larger ICANN community. In order to minimize costs, such transformation should be done using a combination of automated tools, crowd-sourced community efforts where possible, and encouraging Registrants to enhance their own credibility by providing information in English as well.
FIRST DRAFT SUBMITTED
A.1 ALAC commends the Translation and Transliteration of Contact Information PDP Working Group for the work done so far on this important area.
A.2 ALAC considers that Contact Information such as Whois forms an important part of metadata that drives the Internet, and may be of interest to many classes of users including end-users and law-enforcement.
A.3 ALAC feels that transparent access to this information, in a form that can be readily used by end-users, is an important factor that enhances end-user trust and confidence in the Internet.
A.4 ALAC recognizes that in the interests of diversity, Registrants should be allowed to provide Whois information in their own languages and scripts. However, in the interests of the rest of the end-users on the global Internet, ALAC considers that it would be desirable to transliterate and/or translate ('transform') the information provided in non-English languages/scripts to English/Roman.
A.5 If there is no requirement that registration information be also provided in English, it is conceivable that some registrants may attempt to limit transparent access to their Whois information by using relatively obscure scripts and languages for submitting registration information.
A.6 The report points to several potential impediments to making available transformed information, including: (a) difficulty in accurate translations and unavailability of exactly equivalent phrases in English; (b) lack of automated tools for good-quality translations; (c) financial burden of translation; (d) difficulties in re-translating in case of changes to the information provided; (e) the large number of domains, the very large volume of information, and the consequent difficulty in validation of translation; (f) inherent unfairness to information-providers as they may be unable to parse/understand the translated content; and (g) lack of transformation standards that may result in multiple valid but incompatible transformations.
A.7 However, considering increased globalized use of the Internet around the world, it is likely that some of these issues may not pose difficulties in the intermediate term. At this time, English remains the most widespread link language used by diverse communities to understand each other. Many or most registrants are likely to use English as a second language at least, since many technical aspects of the domain hosting require its use (eg., configuring servers using Linux or Window, programming web sites, accessing technical documentation, using credit cards). Further, automated transformation tools do exist for languages used by some of the very large communities (such as Chinese & Hindi).
A.8 Given the desirability of having registration information in English on the one hand, and the existence of several impediments that make mandatory translations infeasible (whether by registrants or registrars), ALAC would like to propose the following approach:
B.1 Whois information is to be maintained in two forms: a mandatory 'canonical' form in the original language, and an optional 'transformed' form after transliteration/translation.The latter should be a close approximation to the original that can be parsed, understood and used by other communities.
B.2 All ICANN databases, forms and documents should provide for capturing, storing and maintaining both the forms.
B.3 Registrars should provide Registrants with the option of entering both forms while creating new entries or editing existing entries.
B.4 Over a period of time, the gaps in information or its validation may taken up through collaborative efforts of Registrars and the larger ICANN community using a combination of automated tools; crowd-sourced community efforts where possible; and encouraging Registrants to enhance their own credibility by providing information in English as well.