[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Two different sets of experiences about non-English identifiers
- From: Joel Rees <email@example.com>
- To: Don Park <firstname.lastname@example.org>
- Date: Mon, 16 Jul 2001 15:39:27 +0900
Don Park expounded:
> HUMAN FACTOR:
> We engineers often forget that, while technical aspect of translating
> tag names to another language might be trivial, human factors are not.
> example, people using the target tag names will not be able to communicate
> well with the original group nor groups using different target tag names.
> This problem can be minimized by using phonetic translation (i.e. Gaijin),
> but the problem does not go away.
My experience is that using the romaji here in Japan generally tends to
compound problems. For single vocabulary words (gaijin, romaji, kimono)
dragged out of context, they can be useful. For Japanese language textbooks
for beginners, they can be absolutely required. For me, taking down notes
during meetings, romanizing is often convenient. But I would not want to use
a romanized DTD. Too many chances for confusion on the homonyms, and
confusion on the meanings of foreign terms is a serious enough problem as it
To be looking at phonetic transliteration is looking in the wrong direction,
> CODE FACTOR:
> XML applications recognize tags by tag names. Unless XML applications are
> designed to support multiple native tag names, code must be modified for
> each target language and repeat for each update. Translating code is
> than translating data.
I don't think much code needs to translated at all.
Imposing a whole new set of operating software (and the operating procedures
that go with it) on the new partner/subsidiary will be extremely expensive,
regardless of the language the tags are written in. Better to set up an
interface, and transform the data shared as it crosses the interface. Tag
names also can (and probably ought to) be transliterated at the interface.
> BUSINESS FACTOR:
> Today's globalization trend makes it less likely for a business to stay
> within its national border during its lifetime. Unless native tag names
> being used as a form of anti-takeover mechanism, I donot see a compelling
> and tangeble reasons not to prepare for likely future.
On a serious note, however, globalization is a fad. A fad useful to various
proselytizing communities, but a fad nonetheless. Like all fashion, it is
based on an illusion. Very few businesses can afford the cost of becoming
Admittedly, if this present civilization survives very long, many businesses
will increase their participation in international commerce. But if I look
at the advantages of imposing some (necessarily foreign) set of DTDs written
in some internationally accepted language, as opposed to letting businesses
define their own data structures in their own language and then define
transforms to interface their systems to the larger context, I see nothing.
No advantages whatsoever.
In fact, the imposition from the outside simply will not work, unless a
company already has a very clear definition of their data structures to
start with. You may perceive the foreign language tags as an avoidable cost,
but I perceive them as an enabler, as one (possible) useful product of a
very necessary step.
> There are probably other factors involved, but these are some I can think
> at this time. Comments?
> Don Park
You talk about the human factors. It seems to me that you are suggesting
that the solution is to proselytize American standards all over the world.
I am an American. I look around me at (for example) the Japanese trying to
run a stable government under a rough transliteration of a mid-twentieth
century idealistic interpretation of the US constitution and I am amazed at
their resourcefulness. There is a lot of stuff in that constitution that
simply works backwards, due to things we quite casually blanket over with
the short phrase "cultural issues", wave our hands at, and try to forget. It
was probably the best that could have been done, but it still creates
Locality of control is a very important principle in engineering. (Lengthen
the control lines, and you introduce both noise and spurious function. Both
increase proportional to the length of the control lines.) To my way of
thinking, requiring XML authors to use tag names borrowed from a foreign
language flies directly in the face of the principle of locality of control.
programmer -- email@example.com
To be a tree supporting all information,
giving root to the chaos
and branches to the trivia,
information breathing anew --
This is the aim of Yggdrasill.
============================XML as Best Solution===
Media Fusion Co. ,Ltd. $B3t<02qhttp://www.mediafusion.co.jp