See my responses below.
>> >>It seems as if we've mostly mastered the technological aspects for
>> >>software that can be localized (by addressing the issues I listed
>> >>The methods for doing these things is becoming widespread knowledge,
>> >>tools for ensuring internationalization are even getting pretty darned
>Does it seem this way because you're not doing the design, architecting or
>implementation of i18n in software products? Software is a moving target.
>technical challenges for i18n come up daily, in the form of new libraries,
>languages, tools, desktop products, standards, etc., not to mention that
>software products in development are pushing an envelope in some way.
>There is more to i18n than what can be localized, by the way.
Even as I was typing the note about having the technological aspects down
pat, I knew it was an overgeneralization, and I therefore apologize. I hoped
people would understand that I meant that the basics were becoming
relatively widespread. (As opposed to the nearly complete lack of awareness
that seemed to be in place only a few years ago.)
Dealing with evolving technology and unstandardized systems and methods will
be an ongoing challenge.
Again, I apologize for my simplification of a complex reality.
>> >>But the focus of all that work and achievement is really on
>> >>allowing all text within the UI to be easily changed. Ok, we also make
>> >>that icons can be changed, but they are a minor factor in the overall
>> >>picture. Localization tasks are primarily centered around translation
>Um, no it's not. Most of my work centers around making the product
>all locales. The l10n team has no work to do in this area. Being able to
>manage emails in several languages at the same time, allowing users to
>any language they want, enabling them to store their personal information
>their own charset - these are the difficult parts of i18n. This is the
>share of my work, and the work of many others in i18n.
Very good point, and again, I apologize for generalizing about less complex
systems than those such as email (and many others). But it seems even these
problems are technology issues, not cultural relativity issues, and that is
partially my point. Developers have so many technological challenges to deal
with, that the cultural ones get lost.
>> >>The conference discussed a wide variety of cultural issues like color,
>> >>and perception of metaphors, teaching methods, eye movement patterns,
>> >>All kinds of issues that are typically never changed during the
>Maybe partly out of ignorance, but more likely out of sheer practicality.
>Gathering this information is not trivial (I believe the conference brought
>that issue), and not cheap. Implementing this level of localization is
>trivial and not cheap. The current ROI for these types of UI changes is
>significant enough to implement, or at least it is difficult to determine.
Exactly. That is why I'm wondering if there might be some methods for
developing software in a way that allows for greater customization without
impacting the code base... (and cost). And why I'm suggesting that allowing
for this level of customization may end up being the next stage in
internationalization's evolution. People used to say that they couldn't
afford to internationalize products up front. Now everyone acknowledges that
it doesn't cost more to do it right, and it saves money later. It's just a
matter of education. Perhaps the same could be true for the next stage in
>Apologies for vehement tone in areas, but my job is not easy and it is not
No apologies necessary, of course. I didn't mean to slight the task or to
imply that its easy. It's far from easy. My intent was to predict the
future, and to ask what people are doing to get us there.
Thanks for the pointers to people who have done or are doing work in the
area! I'll have a look at some of their stuff.
P.S. Wish I had met you at the conference!
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:46 EDT