W3C home > Mailing lists > Public > www-international@w3.org > July to September 2004

Re: I18n recharter should address localizability

From: Tex Texin <tex@i18nguy.com>
Date: Thu, 29 Jul 2004 05:58:42 -0400
Message-ID: <4108CA52.3587F04A@i18nguy.com>
To: kuro@sonic.net
Cc: Tex Texin <tex@xencraft.com>, www-international@w3.org, Yves Savourel <ysavourel@translate.com>

Hi Kuro,

I meant #1, localization within the realm of W3c standards.

Although there may be analogies within other existing technologies, the W3C
needs to address its own standards and cannot depend on tools or techniques
that work elsewhere to work with W3C technologies and certainly cannot presume
that they will be optimal for the W3C environment.

The W3C should be incorporating into its architecture the means to efficiently
localize web content and web services.

For specific examples demonstrating a need for the W3C to address localizaiton,
please look at the Web Services Internationalization Usage Scenarios document I
cited
(http://www.w3.org/International/ws/ws-i18n-scenarios-edit/Overview.html).

e.g. Web Services needs mechanisms that provide for the correct localization to
be channeled through layers or chains of services hosted in different markets,
without burdening the services with the need to transmit large catalogues of
message translations.


It is quite clear that localization is a significant cost for corporations that
support multiple markets or languages. Often figures run into the hundreds of
thousands and millions of dollars. And as web content is frequently updated,
these represent ongoing or recurring costs. (Yes, translation memory and reuse
reduces the recurring cost, but it is nevertheless significant.)

If we can improve the architecture to make localization more efficient, users
of W3C technologies will experience significant savings. This should be a
strong area of interest for W3C members, as the costs for localization are
often tracked within companies and well understood (unlike i18n costs). The
costs are multiplied too by the number of languages localized... So the
potential economic benefit should be clear. There is also a need to improve
time to market.

I can't answer Addison's question of "who is willing to commit?". I hope that
recognition of the potential cost savings will spur some members that
experience these high costs to speak up.

As for deliverables, I would like to see a requirements document created that
identifies the important principles behind:
robust schema or dtd design, 
creation of web content that is efficiently localized,
well defined processes and architecture and tools for localization, and
improved negotiation and distribution mechanisms so the "correct" content is
returned to users, with minimal distribution cost or overhead,


The requirements document should look at the needs of content authors, web
administrators, translators and localizers, schema designers, and web services
developers among others, to ensure that relevant members of the community are
represented and that guidelines, and new localization tools and process
refinements can be envisioned. Other organizations that focus on different
aspects of localization should also be involved.

Yves' suggestion for localization namespace is a good suggestion and the
requirements specification should confirm or establish the need for it.

If a workshop was held on the subject of localization within W3C technologies,
it would help identify players that would commit and would jump start the
requirements document. This has been an effective technique for launching
projects in the past.

The question of where this work should be hosted seems second order to me. Both
the I18n core and GEO groups are good candidates, but both groups also have a
many other tasks and are short staffed. There is something to be said too, that
Localization Architecture is different from I18n architecture, and different
skills and resources should therefore be involved. So consideration to creating
a separate localizaiton working group has merit. Probably such a decision would
be more clear after the requirements document was developed.

I would like to see the issue raised beyond the www-international list, so that
members which may not be subscribed to this list, but which would benefit from
localization cost reduction and improved time to market, would get a chance to
chime in here.

tex



KUROSAKA Teruhiko wrote:
> 
> Tex,
> I'm not too sure what do you mean by "localize applications using
> these technologies".  Do you mean the group should address
> (1) Localization of materials written in XML, HTML and
>      others W3C standards,
> or
> (2) Localization of computer applications in general ?
> 
> If you mean (1), could you give us an example where
> these technologies need special cares than regular
> application localization ?
> 
> If you mean (2), I wonder if W3C is the right place to
> address these concerns although it can volunteer if
> no other organization is doing it.
> 
> > The technologies of the W3C have become very sophisticated, enabling the
> > development of complex, powerful applications. Although these technologies make
> > some provision for language and culture through the internationalization
> > efforts of the organization, it is not at all obvious or easy to efficiently
> > localize applications using these technologies.
> >
> > There are no guidelines within the W3C for architecting applications, or for
> > that matter designing W3C specifications, to insure
> > localizability, or recommendations for processes supporting localization of
> > applications.
> 
> --
> KUROSAKA ("Kuro") Teruhiko, San Francisco, California, USA
> Internationalization Consultant --- now available for new contracts!
> http://www.bhlab.com/

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
Received on Thursday, 29 July 2004 06:00:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:03 GMT