Thanks for sharing this draft.
 
I sent one comment to ICANN (I have not really had time to review the draft in detail).

I generally support ICANN's mixed way of doing these translations--outsourcing them plus managing volunteer reviewers (I note that ICANN is dealing with only a few languages, not the 100's that the W3C translation system deals with, so it should be easier for ICANN to control this process)

However, I sort of oppose publishing a particular machine translation online (although machine translations have improved some).  
 
When a human translation is not available, would simply providing a link to a free machine translator--rather than a machine translation of perhaps poor quality--not be better?  Or would that be too much of a burden on the reader? 
 
(It seems to me that the various machine translators have made use of one another's algorithms, to the point tha, given a particular piece of text, the free machine translation services I am familiar with yield exactly the same results, errors and all.)

 
--C. E. Whitehead
cewcathar <at> hotmail.com

> From: nobody <at> xyzzy.claranet.de
> Date: Sat, 1 Mar 2008 10:49:54 +0100
> Subject: Re: [gnso.secretariat <at> gnso.icann.org: ICANN Draft Translation Programmeopen for public comment]
>
> Stephane Bortzmeyer wrote:
>
> > Since this draft document, open to comments, talks a lot about
> > human languages, I feel it is relevant here.
>
Thanks; Stephane.
> http://icann.org/translations/draft-translation-programme-v2.2-13feb08-en_EN.pdf
Thanks for this link, Frank.
>
> 127 KB PDF, visible with Acroreader 8.1.2 on W2K without crash,
> I didn't look for an accessible non-Proprietary Document Format.
>
> > Do note that the plan for language identifiers, in the current
> > version, is ISO 639 (with just ISO 3166 country codes), not BCP 47
>
> Apparently they use locale indentifiers. After a somewhat obscure
> procedure they arrived at 11 languages for most of their purposes,
> likely they don't need RFC 4646 tags for this job.
Possibly no.
> On the bright
> side, no ECMA 376 numbers Just propose RFC 4646 language tags
> if you think it is important, there is a public comment forum.
>
> Frank
>
Fine with me. 
But I leave that to you two and the rest to decide what to propose here.

--C. E. Whitehead
cewcathar <at> hotmail.com

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages

Hi, all.
Frank, thanks for your reply.  Thanks for pointing out that Korean does have kore as its suppress script; thus these 11 languages should not need a script subtag (unless there is a lot of hanja in a Korean document; I believe hanja is occasionally used some for scientific writing??).
 
(Of course, there is always a possibility, however remote, that one of ICANN's meetings will be held somewhere where there are, for example, two orthographies in use; and ICANN will decide not only to provide interpretation in the language of the host country, but also to make relevant documents available in the host language.  The documents of course still might be provided in a 'default' orthography; however it might also happen that proponents of each orthograpy would offer to provide free transcriptions of the documents into their respective orthographies, & ICANN, for whatever reason, & then of course it might be necessary to use more than a simple subtag to indicate the orthography . . .   Just a wild scenario; but anything is possible.)
 
So I think still that BCP 47 is probably the right call.
 
(Sorry, I'm still reading the draft; I skimmed it initially; it does not seem to mention BCP 47 at all; is that intentional?  Or just an oversight? I've still got to go through it more carefully . . .
Thanks for your patience)
 
Best wishes,
 
C. E. Whitehead
cewcathar <at> hotmail.com
 
y <at> xyzzy.claranet.de
> Date: Mon, 3 Mar 2008 08:23:50 +0100
>
> CE Whitehead wrote:
>
> > I really do not see that there will be much need for scripts
> > to be identified--except for Korean--as the default script
> > should generally serve for ICANN's purposes
>
> I'm not sure why you pick Korean as example, about a year ago
> it got a Suppress-Script: Kore here. Maybe it's my fault, I
> mentioned that one source I checked for the Frisian, Sorbian,
> and German languages didn't confirm "Kore". But that was an
> *old* (roughly 1990) source, TUS 5.0 has a newer reference to
> a KP standard. In other words "ko" should be fine for ICANN.
 
Sorry. You are right; in July of last year ietf chose kore as it's suppress-script after some discussion; though there is another script.
It was the only language on the list for which I could think of an issue.
Sorry.
 
--C. E. Whitehead
cewcathar <at> hotmail.com

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages