Re: Three new I-Ds re. URL i18n

On Fri, 1 Aug 1997, Gavin Nicol wrote:

> >> Your proposal is a patch over a broken design.

It is an i18n patch for an i18n problem. The patch you
propose is the same, only smaller, i.e. it makes only
half-way progress for i18n. I don't see the connection
with the rest of the desing, whether these are problems
or features. If you see a connection, then it is:

- Either you don't think it is necessary to have a full
	i18n patch, because the design is broken anyway.
- Or you think we should better not fix it with respect to
	i18n, because otherwise it may stay longer, and it
	would be more difficult to see the other problems.


> >>If we had clean seperation, there would
> >> be two problems: I18N of naming, and I18N of searches. They
> >> could have the same technical resolution (use UTF-8), but that
> >> doesn;t mean to say they need to share the same *mechanism*.
> >
> >Having the same technical solution simplifies implementation.
> >And internationalized they need to be anyway. The question
> >of whether we would be better off with two separate mechanisms
> >is an interesting one, but it is independent of the question
> >of how to do internationalization.
> 
> I disagree. The definition of the mechanism could have a drastic 
> effect of the strategy to use for I18N.

Well, if we started something new, we might indeed get i18n right
from the start. But then, would this "something new" catch on?

In fact, we already have file upload, which looks like your perfect
solution: Query is sent as body, not in URL, and it's easy to add
a charset parameter, which is very close to what you propose for
the header. We would all be very happy if this worked and we could
just tell everybody that the problem is solved. But appart from
the fact that Netscape has implemented file upload, allegedly without
a "charset" parameter, I don't remember having heard of much progress
in this area. I have no idea why. Maybe you have.


Regards,	Martin.

Received on Friday, 1 August 1997 15:40:44 UTC