|
|
As of today, I’m no longer at Sun. After eight years of working on Java
internationalization I feel it’s time to take a break and look at the world
from a different angle.
Working here has been a long and interesting ride. When I joined Sun,
the Java programming language already based all text handling on Unicode
(back then thought of as a 16-bit character encoding), and JDK 1.1 had
shipped with new internationalization APIs that promised to make it easier
than on any other platform to develop multilingual applications. However,
not everything worked as advertised, so it was a time of frantic bug fixing.
At the same time, we had to find a solution for the famous RFE
4040458 and provide
input method support for lightweight components such as those of the emerging
Swing toolkit – not easy because for the 1.1.x line we had to provide a
solution without adding any API. The full-fledged input method client API
showed up in J2SE 1.2, and the input method engine SPI finally in J2SE
1.3.
This SPI started the process of opening up the Java internationalization
architecture so that third parties can extend the locale support that Sun
provides. The charset SPI followed in J2SE 1.4, and the locale sensitive
services SPI and the ResourceBundle.Control class
in Java SE 6. As I wrote
earlier,
the missing pieces are font rendering and user interface localization.
The set of supported writing systems expanded from European and East Asian
writing systems in JDK 1.1 via Arabic and Hebrew in J2SE 1.3 to Thai and
Devanagari in J2SE 1.4. The Currency class, which would have
been really useful for the earlier transition to the euro, was added in
J2SE 1.4. In J2SE 5.0, we had to implement supplementary
character support because Unicode had really moved beyond the
limits of a 16-bit character encoding. In the same release, multilingual
font rendering enabled multilingual applications on the client side.
Localization made a big jump forward in J2SE 1.3.1: Before that, different
sets of languages were localized for the different platforms, and for some
platforms separate localized versions were produced months after the English
release. Sometimes we couldn’t ship the localized versions of release n at
all because they were finished only after the English version of release
n+1 had shipped. I thought that’s nuts, so starting with J2SE
1.3.1 there’s been a single download bundle for each platform that includes
all available localizations, which also means they all ship simultaneously.
Outside of Java SE, I worked with the Java EE web tier team to correct
problems in the servlet and JSP APIs, which, like so many new technologies,
had initially been developed without consideration for internationalization
and then retrofitted over several releases. In the Servlet 2.4 and JSP
2.0 specifications we finally made it possible to reliably specify character
encodings for all text input and output, as is necessary for multilingual
web applications. I also worked with a few other internationalization
experts at Sun on generic
internationalization requirements.
What still hurts after all these years are mistakes that we can’t correct
because of compatibility risks or where the fix would mean complete replacement.
Counting months from 0 was a silly idea; merging two different
representations of a point in time and the algorithms to map between
them into a single Calendar class a serious design mistake.
The use of apostrophes to quote uninterpreted sections of a MessageFormat pattern
string still complicates localization processes, especially for French
and Italian. And using ISO 8859-1 as the only supported encoding of properties
files and as the default encoding in servlets and JSP pages needlessly
complicates application development – UTF-8 would have been the right choice.
At least these specifications have the excuse that they were written when
UTF-8 was not widely supported yet. There’s no such excuse for Sun’s new
bug
tracking system, released in 2004.
Over the years, my team has had ten engineers and seven managers. The
number of managers is comparatively high because they don’t last as long
as engineers and because for a while HR rules required us to have separate
managers for our sites in the US and in Japan.Two engineers
also served as managers, and two engineers moved from Japan to the US.
John joined the
team twice and recently rejoined Sun as a technical writer. Masayoshi started
before me and stays after me.
But Java internationalization
has always been a collaborative effort: The original internationalization
APIs in java.text and java.util were
largely designed by the internationalization team at Taligent, and that
team (now part of IBM) has contributed code to every major release since
then; the input method framework was designed in collaboration with Omron,
Justsystem, and Apple before there was a Java Community Process; the
support for supplementary characters was designed by the JSR 204 expert
group; the
charset API was part of JSR 51 and implemented by the Libraries team;
many other Java SE and Java EE engineering teams do the necessary work
on their components; the quality assurance teams help find the bugs;
and Sun’s central Globalization team helped with early implementation
efforts. Geographically, we’ve had contributors in Silicon Valley, San
Francisco, Tokyo, Yokohama, Kyoto, Tokushima, Beijing, Bangkok,
Bangalore, Jerusalem, Cairo, Prague, Dublin, New York City, Ventura,
and some whose physical location I never found out. Thank you to all
of you.
Scott McNealy recently wrote about the community
effort needed to eliminate the “digital divide” and will give a related
presentation at JavaOne.
Software globalization of course is one of the critical pieces
in this effort. A language barrier is a pretty effective divider. If software
isn’t capable of rendering text and accepting input in the user’s language(s),
it’s not very useful. If the user can’t understand the user interface
because it’s in a foreign language, her use of the software will be limited
as well. And if the software doesn’t fit into the cultural, legal, and
business environment of its intended users, it may not matter how
cheap it is.
So I’d like to survey where we stand with Java internationalization
and localization, how we enable the community to contribute, and what the
remaining issues are.
One acronym you’ll see several times is “SPI,” Service Provider Interface
– by this we mean public interfaces in the Java platform APIs that let
third-party developers extend the functionality of the Java runtime through
new classes (and some identifying information) that are installed into
the runtime’s extension directory. SPI’s are one way to enable the community
to provide support for additional languages.
Unicode
The foundation of Java globalization is the Unicode character
set – the Java platform now supports Unicode 4.0. Unicode has always endeavored
to include all languages used on planet Earth, but a
number of writing systems still have not been encoded. Encoding a writing
system requires detailed knowledge about its use in real life as well as
about how it would be processed in software, so it’s often difficult work.
Supporting the Script Encoding
Initiative may be the best way to help.
Character Encoding Conversion
While the Java runtime uses Unicode (more precisely, UTF-16) internally,
much of the world’s data is stored in other character encodings. The JRE
already supports a long list
of character encodings, but the Java platform
also provides an SPI that lets developers add any other encoding that may
be needed.
Locale and Currency Identification
The Locale class currently is based on the ISO standard 639-1 for languages
and 3166 for countries. ISO 639-1 covers about 200 of the most important
languages, but estimates for the total number of languages on planet Earth
range in the thousands (many of them near extinction). There’s still plenty
of work to do to support just the ISO 639-1 languages, but using the three-character
language codes of ISO 639-2 or an extensible standard such as RFC 3066
(or its successor)
may eventually be necessary to enable even broader coverage. For countries
and currencies, the situation is simpler: The JRE knows all of them.
Date and Time Handling
The Calendar class
was intended to enable support for all calendars used in the world, but
it turned out that its design was hard to understand, difficult to subclass
correctly, and not extensible enough for complete coverage (the Balinese
calendars, for example, just don’t fit into the
mold). Support for the world’s calendars has therefore been slow in coming:
The JRE provides only the Gregorian, Thai Buddhist, and – starting with JRE
6 – Japanese
calendars. A complete solution will likely require a new API/SPI combination.
In the meantime, the ICU4J library provides a separate, somewhat incompatible
Calendar class
with several additional calendar implementations.
For time zones, the situation is simpler: The JRE knows all of them.
However, there is a little problem with keeping the information up to date:
Politicians in some countries like to tinker with the daylight savings
rules, often with little advance notice, and so the time zone rules in
the JRE don’t always match reality. More frequent updates of the JRE time
zone data may be one solution; productizing the tool that we use to update
the data may be another.
Names of Languages, Countries,
Time Zones, and Currencies
The JRE has traditionally provided complete sets of these names and symbols
for about 10 languages, and smaller sets for another 30 or so languages.
A new SPI in
Java SE 6 enables third parties to provide more. As I mentioned in my blog
about this SPI, there’s the idea of creating an extension that uses
the SPI to support all locales that the Unicode Consortium’s Common
Locale Data Repository provides but the JRE doesn’t. This means that
community members who want to extend the set of supported locales may have
two ways to contribute: Directly by implementing an extension using the
SPI, or indirectly by contributing data to the CLDR.
Text
Processing
The text processing functionality in the java.text package
supports about
100 locales (more
in JRE 6). The discussion of the SPI and CLDR in the previous section
applies to this functionality as well.
Text Input
Text input in the Java platform typically relies on the host operating
system. For cases where the host OS’s facilities are insufficient, the
input method engine SPI can be used to implement both full-fledged input
methods and simple keyboard remappers. The JRE itself comes with input
methods for Thai and Devanagari, Naoto’s
article provides a few more, and several third-party input methods
exist.
Text Rendering and Editing
The JRE currently supports 11 of the Unicode standard’s 60 writing systems.
Extending this set is where the really hard problems are. Text rendering
and editing are complex processes that don’t lend themselves to the creation
of SPI’s. They also require extensive testing, which is hard to automate.
Testing has been the main bottleneck so far. Some of the currently
“supported” writing systems don’t receive any systematic testing. Several
additional writing systems (including the ones supported by
our Indic
input method) are implemented, but we don’t document them
as supported because they’re complex and the risk of failures is too high.
Community help therefore would be most useful in the area of testing.
User Interface Localization
The JRE’s user interface is currently provided in ten
languages, the JDK
tools in three. To enable others to provide additional localizations, we’re
currently evaluating whether we can document the main user interface
resource bundles and how to create and install additional ones. This
wouldn’t be the same as an SPI – resource bundles are easier to
create, but there would be no guarantee of compatibility from release
to release as there is for an SPI.
Documentation and Community Interaction
Sun currently provides documentation about the Java platform
primarily in English, with significant amounts translated
into Japanese, small amounts into Chinese and Korean, and nothing in
other languages. Input from the community is pretty much only accepted
if
it comes in English. It’s been recognized that these are serious problems,
and some efforts are underway to provide more documentation particularly
in Chinese. However, much more is needed to engage developers worldwide
and forge a global community without language barriers.
OK, the name of this new feature in Java
SE 6 has become more complicated
than we’d like it to be. What this “Locale Sensitive Services SPI” really
means is that third parties can now provide implementations
of most locale sensitive classes in the java.text and java.util packages
for locales that aren’t yet supported
by the Java runtime.
“SPI” stands for “service provider interface,” a pattern that some developers
are already familiar with from developing character converters, input
methods, or other extensions. In this pattern, the Java platform provides
interfaces or abstract classes that a developer can implement or subclass.
The implementations or subclasses are then packaged with some descriptive
information and installed into the Java runtime’s extension directory,
and become available to applications through factory methods of the Java
platform.
The locale-specific implementations that can be provided through the locale
sensitive services SPI are:
Each of the classes mentioned above now has a corresponding abstract provider
class in the java.util.spi or java.text.spi package. Concrete provider classes
advertise the locales they support through their getAvailableLocales methods;
these locales get added to the lists returned by the getAvailableLocales methods of the corresponding API classes. If an application requests an object
for a locale that the JRE doesn’t support, a provider that supports the locale
is asked to provide the necessary object.
An alternative to using an SPI might have been to simply document the format
of the resource bundles used in implementing the java.text and java.util packages. This however would have required freezing the current format of
the resource bundles, and we weren’t quite ready for that (in
fact, we did redesign it for JDK 6). It would also have prevented the implementation
of objects such as collators and break iterators that may require locale-specific
code or data that doesn’t fit into the existing resource bundle format. Using
an SPI gives developers complete freedom in the design of their implementations.
We also considered importing the complete data of the Unicode Consortium’s
Common Locale Data Repository instead
of providing an SPI. The CLDR covers about twice as many locales as Sun’s
current JRE. However, importing the complete CLDR data would have added substantially
to the JRE download size while still not helping users of locales that are
not (yet) supported in the CLDR. Instead, we only used CLDR for a few additional
locales. We think
however that it would be worthwhile creating an extension that uses the SPI
to support all locales that the CLDR provides but the JRE doesn’t. If you’re
interested in helping with such a project, please let
us know.
It’s official: The next version of the Java platform won’t have a “2”
in its name anymore. The successor to Java™ 2 Platform, Standard Edition
5.0 (J2SE 5.0) is going to be Java™
Platform, Standard Edition 6 (Java SE 6). Similarly, new versions
of J2EE and J2ME will be Java EE and Java ME. The name change doesn’t
affect currently shipping products, so it’ll be a long transition. But
reducing the number of numbers in the product name is clearly a change
for the better.
Did you ever wish you had a little more control over the ResourceBundle class?
Say, have it instantiate bundles from XML files or from data in a database,
rather than just class and properties files? Or, to the contrary, have
it look only for properties files, because you never use class-based resource
bundles? Or have it reload a bundle with a little fix without having to
restart your web application, which otherwise is on the way towards reaching
99.999% uptime? Well, you just got that little more control: The ResourceBundle.Control class
in JDK 6.
The central method in ResourceBundle has always been getBundle.
This method looks for resource bundles of predefined types in predefined
places using a predefined search strategy, loaded them in predefined ways,
and cached them in a largely unspecified way.
The idea of the Control class is to expose every major step
of the bundle loading process as a separate method that can be overridden
and customized. The Control class itself implements the methods
so that using it directly results in the same behavior as in previous releases.
But applications can subclass it, override as many methods as necessary
to implement the behavior they need, and pass an instance of this subclass
to new getBundle methods
that accept Control objects.
For some of the most common cases, you don’t actually need to write your
own subclass: If you just want to use only class-based or only properties-based
resource bundles, or if you want to avoid the fallback to the default locale,
the getControl and getNoFallbackControl methods
provide you with ready-made instances.
Here are a few examples for how you can go further (the class description
has more):
- To search for bundles according to the list of languages that your
web application received in an Accept-Language HTTP header, override
the
getFallbackLocale method to successively return the locales of the
language list.
- To load resource bundles from locale-specific directories rather than
using locale-specific suffixes, override the
toBundleName method
to insert the locale ID components into the appropriate places of the bundle
name.
- To use bundles for Chinese/Taiwan as the parent bundles of Chinese/Hong
Kong bundles in order to share traditional Chinese strings, override
getCandidateLocales to
insert the Chinese/Taiwan locale in the right place.
- To ensure that cached bundles are checked against their source files
on disk at least every 6 hours, override
getTimeToLive to
return 21,600,000. (The specification currently says that that’s the default
behavior. Unfortunately, this uncovered a bug in a major third-party application
that we test with, so in order to avoid incompatibilities, the default
behavior will revert to TTL_NO_EXPIRATION_CONTROL, which reflects behavior
in previous releases.)
Some methods need to be overridden together. For example, if you override
getFormats to
return formats other than "java.class" and "java.properties", you also need
to override newBundle to
load bundles of these formats. If, in addition, you override getTimeToLive
to enable checking whether a bundle in the cache is still up to date, you
may also need to override needsReload to
implement the checking.
If, instead of periodically checking whether resource bundles in the cache
are still up to date, you’d rather remove all your application’s bundles
from the cache when installing new bundles, you can use the new ResourceBundle.clearCache methods.
As always, we’d love to hear from you whether these API additions meet your
needs, or what’s wrong with them. Please try them, file
bugs, or send us your feedback.
If you pay close attention to the return values of the getAvailableLocales methods
in the java.text and java.util packages, you
may have noticed that the lists got a little longer in recent builds of JDK
6. The additions to the already long list of supported
locales in JRE 5.0 are:
| Language |
Country |
Locale ID |
| Chinese (Simplified) |
Singapore |
zh_SG |
| English |
Malta |
en_MT |
| English |
Philippines |
en_PH |
| English |
Singapore |
en_SG |
| Greek |
Cyprus |
el_CY |
| Indonesian |
Indonesia |
in_ID |
| Japanese (Japanese calendar) |
Japan |
ja_JP_JP |
| Malay |
Malaysia |
ms_MY |
| Maltese |
Malta |
mt_MT |
| Spanish |
US |
es_US |
You may wonder how we picked these locales. OK:
- One group is based on IT market sizes in the IDC Worldwide Black Book,
from which we selected all countries above a certain market size. We
also looked at the languages spoken within these countries, and tried
to guesstimate IT market size for those. For example, 11% of the US population
now speak
Spanish at home, and at least in the consumer space companies can
no longer afford to ignore this.
- Then we added locales to cover all countries in the European Union
with their main languages. Malta is a small country, but it’s a member
of the EU, Maltese is an official EU language, and some business in the
EU simply requires support for all EU languages. As it turns out, the EU
added Gaelic to its official languages just as we finished the addition
of these locales, so we’re already behind again.
- The new Japanese locale finally is the way applications can access
the new Japanese calendar, which is not exposed as a separate class in
the API. To obtain an instance of the Japanese calendar, you’d use
Calendar.getInstance(new
Locale("ja", "JP", "JP")).
The additions mark the first time that we use data from the Common
Locale Data Repository for the JRE. The CLDR is maintained by the
Unicode Consortium with contributions from IBM, Apple, Sun, and many
others. We intend to continue to use CLDR for new locale data in the
JRE. It’s an open question whether we should also update existing data
from this source – it might fix some problems in our data and improve
the alignment between the JRE and other software products, but it may
also be seen as an unnecessary incompatibility. It’s pretty common for
locale data to have two or more different versions that are all acceptable
to users, while random changes between these versions are not acceptable.
If you have an opinion on this issue, please let us know.
The JavaOne 2005 schedule
is now available, and there are several opportunities to learn about internationalization
and to discuss issues you may have. Several sessions focus on internationalization:
In addition, a special “Ask
the Sun Experts” event during the JavaOne Pavilion
Reception on Monday night features a table with members of Sun’s Java Internationalization
team. If you’d like to find out about processing of supplementary characters,
rendering of Chinese text, building an XML-based resource bundle, breaking
Thai text into lines, or where to find the Octoberfest in Yokohama, please
join us. You do need to register though.
Andrea Vine, a leader of internationalization at Sun, has been writing a
series on “Internationalization Myths” – ideas about internationalization that
many engineers (and VPs!) at Sun and other companies have but that just aren’t
correct. If you think any of the following statements is true, head on over
to her blog for an update:
[Updated with the final installments 2005-05-25]
JDK 5.0 Update 3 shipped
today, and with it a new feature for Chinese developers: The JDK tools have
been localized into simplified Chinese. The JDK thus joins other tools such
as NetBeans and Java
Studio Creator in recognizing the growing importance of the Chinese developer
community. The localization is also available in JDK
6.0, starting with last week’s build B33.
The tools of the Java™ 2 Platform Standard Edition Development Kit
(yes, that’s the full name of the JDK) are now localized into three languages:
Simplified Chinese, English, and Japanese. The Java™ 2 Platform Standard
Edition Runtime Environment (more commonly known as JRE) continues to be localized
into ten languages: Simplified and traditional Chinese, English, French, German,
Italian, Japanese, Korean, Spanish, and Swedish.
2005-04-28 (Donnerstag)
–
Comments [0]
A new article about features under development for JDK 6.0 has a section
on internationalization
features. The big theme is opening up
the architecture of the internationalization frameworks – enabling different
implementations of resource bundles as well as the provision of locale data
for locales that Sun doesn’t know enough about. The long awaited normalization
API and a Japanese calendar round out the feature set.
Developers working on the server side should read this section of the article
despite the article’s title – all listed internationalization features are
part of core Java and useful on both desktop and server. The Java Internationalization
team just happens to be part of the Java Client Group at Sun, and so we got
invited to participate. Developers working on desktop applications of course
will want to read the entire
article.
Build 29 of JDK 6.0 is
notable for something it doesn’t have anymore: The sun.io package.
This package provided since JDK 1.1 the character encoding converters that
were accessed through methods on java.lang.String and several
classes in the java.io package. The sun.io package
has now been completely replaced with implementations using the newer java.nio.charset interfaces.
It’s likely that some developers have created additional classes in the sun.io package
to support encodings that the JRE didn’t support itself. Since J2SE 1.4,
of course, the platform has provided a better way for this: The service
provider interface in the java.nio.charset.spi package,
which lets anyone create character encoding converters that can be plugged
into any Java runtime. If you happen to rely on sun.io, this
would be a good time to migrate to the new SPI.
When getting cash this week, I noticed that the ATM had learned two new
languages: Korean and Vietnamese. That’s in addition to the four it had
already mastered earlier – English, Spanish, traditional Chinese, and Hmong.
Wells Fargo is one of a growing number of American companies
that have realized that multilingual software isn’t just required for their
global success, but that it’s also good for business at home. Their press
release provides some background; the US Census Bureau report “Language
Use and English-Speaking Ability: 2000” has more.
 Pictures
of a must-have
novelty have been popping up all over Java-related web sites recently,
including on James
Gosling’s blog. Duke briefly
introduces the inventor, Kazuhiro
Kazama, and mentions Kazama-san’s activities
around Project Looking Glass. But what Duke forgets to tell us is that
he and Kazama-san have been friends for a long time. Kazama-san has helped
Duke on two expert groups, JSR
51 (New I/O APIs) and JSR
204 (Supplementary Character Support). He has translated and improved
the one and only Java
Internationalization book into Japanese.
He’s a driver of Ja-Jakarta,
the Japanese group of users and developers of Tomcat
and related technologies. And he’s always ready to provide Duke and
his helpers with advice, in particular on the needs of Japanese developers.
Here he is, discussing servlet character encoding issues with Servlet
specification lead Yutaka Yoshida at the Java Technology Conference in
Tokyo, February 2004.
It’s well understood that localization can increase sales because users
prefer to use products that use their own language rather than a foreign
one. But it may be less well understood that localization can also
reduce support cost. OK, here’s some evidence:
This graph, provided by Sun’s Consumer Java Support team, shows the number
of support incidents per week and language on Sun’s
Java consumer site before and after the help and FAQ contents
related to JRE 1.4.2 were localized into the given languages. What a
steep drop!
If you think about it, it all makes sense: Given the choice between digging
through support information in a foreign language and submitting a question
in their own, many users opt for submitting the question, even though they
have to wait for an answer. Some users may not be able to read English
at all, others may just find it too difficult. Given the choice of digging
through information in their own language and submitting a question, the
outcome changes: Users get their answers online, and Sun saves money.
At this week’s Sun Engineering Conference, my contribution was a call
to use Unicode everywhere.
What’s new about that? Hasn’t Sun been using Unicode for years? Yes, of
course we have, because Sun requires all revenue products to be internationalized,
and using Unicode is usually the first step in internationalizing modern
software. Java has been based on Unicode since version 1.0, Solaris offers
a wide range of UTF-8 locales (UTF-8 is a Unicode character encoding),
StarOffice uses Unicode for text processing, and so on.
The problem is in the systems that we use to communicate with customers
and other partners but that aren’t considered products. These software
tools and web applications often don’t use Unicode and so impose random
restrictions on the languages that can be used. And that’s bad because
Sun has partners worldwide and needs to speak their languages
and listen in their languages.
One negative example is our bug tracking system. This is not a creaky
relic from the last millennium, but a brand-new system, developed within
Sun, deployed in summer 2004, and using the whole range of modern software
technologies. The main front end for Sun-internal use is a Java Web Start-deployed
Swing application, which of course lets you input characters in any of
the 14
writing systems supported by the Java platform. But if you try to save
a bug report that contains, say, Chinese characters, you get this lovely
alert:
The reason is that the back end system has been configured to use the
ISO 8859-1 character encoding, which restricts all text to English
and a few other western European languages. Text in any other language
cannot be stored in any text field. The only workaround is to store it
as a binary attachment, which makes it inaccessible to search and difficult
to access in general.
As part of opening up its development processes, Sun also offers a front
end for public use, the bugs.sun.com web
site, which allows anybody to submit and track bug reports against a number
of Sun products. Following the lead of the bug database, this web site
also uses ISO 8859-1 for all text. In this case, if a user includes
non-Latin text in a bug report, she usually won’t even get an alert – the
browser will just silently convert the text to question marks or, if we’re
lucky, to numeric character references, making it rather difficult for
engineers to understand what the bug is about. The web site does not accept
or display attachments, so the workaround for the internal front end is
incompatible with the public front end.
The reason given for the restriction to ISO 8859-1 is that all Sun
employees speak English, and therefore internationalization isn’t necessary.
This obviously ignores that a bug tracking system isn’t just about Sun
employees communicating with each other; it’s about customers and developers
communicating with Sun employees about problems that customers have when
processing their data. The data can be in any language that customers use,
and so the bug tracking system needs to be able to represent text in any
language. Removing “those characters” may make it impossible to investigate
and fix a bug.
The language in which customers, developers and Sun employees communicate
about bugs is a separate issue from the data. Sun obviously prefers such
communication to be in English, because it makes it easier for us to pass
the information around within Sun. However, if a customer speaks only Thai
and runs into a problem in processing Thai text using Sun products, wouldn’t
we prefer that she submit a bug report in Thai rather than immediately
switching to a competitor’s product? Most Sun engineers don’t speak Thai,
but some do, so we can get help if necessary – if the text survives in
the bug tracking system.
The bug tracking system isn’t the only tool that obstructs communication
with unnecessary technical restrictions. Other examples include the software
behind the Java developer forums,
which corrupts non-ASCII text and so makes
it difficult for developers to discuss internationalization problems,
and the developer
feedback forms, which use ISO 8859-1 and so block feedback in
non-Latin languages.
Sun has realized that open communication with customers, developers,
and other partners is critical to its future success. Limiting the communication
to English or a small set of other western European languages means limiting
our success worldwide. That’s why using Unicode everywhere is an important
first step. The site on which this blog appears, blogs.sun.com,
shows the way: It enables daily communication between Sun and the world
in Chinese, English, and Japanese; and occasional blogs in French, Hungarian,
German, and Korean show that more is possible. All components of blogs.sun.com,
of course, use Unicode.
|
feed