"Craig R. McClanahan" wrote:
> This is a noble idea, but I don't know how accurate it will really be. For
> example, the European subsidiary of the company I work for has a ".com"
> extension on their domain name,...
Yes, you're right. You can never count on domain names for accurate information.
I think this class could still be useful, though:
I'm planning on using it to generate -default- user information for first time
visitors to a web site. So, in this case, it'd be ok to default to Locale.US if
no other info is known. Registered users could then specify their timezone or
language directly.
---
I've already had a new idea for the design of this class, by the way. Instead of
building a hash table of TLD -> Locale mappings by hand, the
DateFormat.getAvailableLocales() method can be used to get a list of all installed
locales (which is much larger than what's defined in java.util.Locale.) Then, the
2-letter country code can be gotten from each locale and used as a TLD lookup key.
I've also decided a new method should be added: getLanguages(), which would
return a list of languages spoken in the country indicated by the TLD. This
lookup can also be built automatically as described above. I haven't thought
about what data structure would be best suited for these various mappings.
- Robb
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
