Flavors of Hepburn (was: Re: Ietf-languages Digest, Vol 81, Issue 41)

Mark Crispin mrc+ietf at Panda.COM
Sun Sep 27 21:45:34 CEST 2009

On Sun, 27 Sep 2009, Doug Ewell wrote:
> Well, that might be perceived as a point of disagreement.  It could be 
> argued that "Hepburn romanization" is not sufficient to convey the 
> meaning "any romanization of Japanese that fits the Hepburn model better 
> than it fits other models," and that this needs to be explicitly spelled 
> out in the Description field or in a comment.


I contend that "any romanization of Japanese that fits the Hepburn model 
better than it fits other models" is a good definition, is reasonably 
concise, and ought to be used in the registration.

> I don't happen to agree, 
> and in fact I would argue the reverse of what you wrote: the more 
> strictly something is to be interpreted, the more normative the language 
> needs to be.

My experience suggests that the less normative the language, the more that 
it will be misinterpreted regardless of whether the desired interpretation 
is to be liberal or strict.

More normative language is always a good thing.

> Language tagging isn't for the utterly and completely clueless.

Perhaps not; but the utterly and completely clueless will tag.  Or expect 
you to tag according to their cluelessness.

If I tag something as ja-Latn-Hepburn, I don't want to receive a bug 
report that I misused the Hepburn tag for content that does not precisely 
comply with Hepburn's 1887 dictionary.

If I tag something as ja-Latn, I don't want to receive a bug report that I 
failed to tag it as Hepburn because it wrote "shi" instead of "si" (but is 
not strictly Hepburn in other ways).

I especially don't want to face both demands simultaneously.

> If some 
> users interpret "Hepburn romanization" to mean precisely and only the 
> system published in Hepburn's 1887 dictionary, and others interpret it 
> to mean any system that writes "shi" instead of "si", the sky will not 
> fall either way.

Maybe, maybe not.  It all depends upon the impact of the disagreement. 
And who disagrees.

If you are a little developer, the specification is vague, and what you do 
disagrees with a [big vendor] product to the point that bad results happen 
to users, then you are wrong by definition.

And if you yield to [big vendor]'s interpretation, and your having yielded 
subsequently creates bad results to users of [other big vendor]'s product, 
then you are wrong by definition.

At this point, you get teed off at the specification for being vague. 
Vague specifications are not the developer's friend.

-- Mark --

Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

More information about the Ietf-languages mailing list