Re: Re(2): Localization and Internationalization

> From: Gavin Nicol <gtn@eps.inso.com>
> Date: Mon, 4 Aug 1997 12:08:28 -0400
> 
> >Similarly, if the vendor knew I was in Luxembourg it could only show
> >me models of shoe that conform to official Grand Ducal footwear norms
> >and regulations, or it could give me the address of the local cobblers
> >providing technical support and so on. Localisation in this sense
> >lends competitive advantage.  
> 
> A long time ago now, I proposed adding some tags for
> locale-independent markup of measuremetns etc. so that browsers could
> display it in most appropriate manner. We had these in one of the
> early drafts too. 
> 
> I think such tags are still useful, but I also think we do need some
> way of profiling users, because there are a large number of things
> that can have an effect on prices, for example. Hasn't there been some
> work done on specifying user profiles in the PICS effort?
> 

There are at least major themes runnning through this discussion that
would be good to keep separate.

 1. markup issues for cultural-dependent values
 2. user profile/preferences
 3. dynamic presentation of content
 
The original proposal for "locale-sensitive" markup contained too many
problems to be resolved in RFC2070 specification. (A similar situation
happened with the MATH markup proposed in the original HTML++ (aka the 3.0
expired spec)). 

Now might be a good time to resurrect the tags that were dropped from 
the original I18N spec. If they were presented in terms of an XML
DTD they might get on a faster track than an HTML 5.X deliverable.
(See http://www.geocities.com/WallStreet/Floor/5815/ "XML/EDI")

There has been a lot of recent activity at the W3C in terms of 
user profiles in the area of privacy preferences. Some information
is restricted to W3C members, but you can find some relevant pointers 
from the Privacy activity page at http://www.w3.org/Privacy/ .
  
As far as the presentation aspects of cultural-dependent information,
I'd like to keep the door open for client-side or server-side resolution
of the presented values. If I had an applet rendering my preferred units 
and my preferred price information, I'd most likely tie it into my
local bank's posted exchange rates to see the current (real time?) price.
(When the document is printed or mailed to another user, the right 
thing happens for their specific environment.)

Received on Monday, 4 August 1997 13:57:04 UTC