Hello,
I don't want to go too far off topic here, but I'll respond to the
points as I do think it illustrates one of the uses of entities
(localization)--which would apply to some degree in XHTML (at least for
entities) as well as in XML.
Kristof Zelechovski wrote:
Using entities in XSL to share code was my mistake once too; it is
similar to using data members not wrapped in properties in data types.
XSL itself provides a better structured approach for code reuse.
Unless you're talking about variables, I guess I'd need elaboration, but
I don't want to go too far off track on list here...
Being able to use localized programming language constructs is at the
same time trivial (replace this with that),
I think that depends on how familiar the script and language is to you
(cognates help many non-English Europeans, whereas the same does not
apply elsewhere). To take some of my wife's family younger cousins, for
example, who are not particularly educated yet who use computers as many
Chinese do, they found it much easier to get a grasp of this "Chinese
XHTML" than the English one, even though they had had some previous
English instruction. I think actual research would need to be done on
this, since it is well possible that only programmer types make it past
the barrier to entry, and then, they may be even more inclined to
dismiss the benefits for others less skilled; i.e., "I did it, so others
should", or they want to get away from their linguistic background
distinctiveness, or have perhaps irrational fears that this would lead
to their people being satisfied with lower standards, etc. (just as many
oppose bilingual education even while it may even help transition
students to the mainstream language).
expensive (you have to translate the documentation)
Not sure what you mean by cost of translating the documentation. Cost
for whom? If your audience is intended for that audience--e.g., Chinese
code at a Chinese website--who needs to translate anything? On the
contrary, they avoid the need to translate...
and not that useful (you freeze the language and cut the programmers
off from the recent developments in the language).
I don't think it would be that hard to update the translating
template--it's not that difficult. But I'm definitely not talking about
relying on this anyways. There are big advantages to having a common
language as far as the ability to learn from others' code from people
around the world, etc. But just as I replied to someone on another list
who said this was not "semantic", this is very much semantic to those
for whom it is their native language--perhaps even more in the spirit of
pure XML (though Babelizing semantics even further, no doubt, if people
actually starting using this on a large scale, as search engines would
have to be aware of either the post-transformation result or the
localized XML, etc.).
Languages tend to use English keywords regardless of the culture of
their designer because:
1. no matter how deep you go, there is always a place where you have
to switch to English in order to refer to some precedent technology,
Yes, like in my use of <?xml-stylesheet?> (though no doubt browsers
could be fairly trivially programmed to recognize localized processing
instructions, as well). Anyways, again, I'm in favor of a common
language, and would even hope very much that countries around the world
could democratically agree on an official standard (including possibly
English, which if its use is as widespread and popular as its proponents
believe, should have little problem obtaining a democratic majority) so
that children will everywhere begin earlier to have access to such a
common language. Nevertheless, if you're a beginner, having to deal with
one line of English is a lot easier than having to deal with a whole
syntax in English, if that's not your native language. I think the fact
that a number of open source projects I've encountered still have not
only comments but also even variables in the programmer's original
language is evidence that there is some desire for convenient
localization. If you have tools that translate it before serving the
code, it is still available anyways.
2. the English words/roots used in the language design often have a
slightly different meaning from the English source,
Maybe, but it is much easier to learn a few exceptions which are
probably at least related in meaning, than to have to learn something
completely foreign. Would you like to learn an Arabic-script XHTML, even
if there was a one-to-one mapping from your keyboard already? Of course
you could, but you have to admit it would take a little time out for
you, especially if you were not already inclined to do coding/markup.
It's not only a vocabulary issue here, but a script issue too--moreover,
using that script may force you to switch between your keyboard layouts
each time you want to make a document.
3. they are sufficiently few to be learned easily; it may be harder to
grasp what they actually mean in the particular context.
(Toy languages for children make an exception, of course; however,
even children tend to mock them nowadays.)
While I am also not arguing that it is ideal to perpetually rely on a
crutch, a temporary crutch is not always bad, and there are plenty of
children as well as the many creative adults who might be drawn into
programming if the barrier to entry were lower. I'm not talking about
localizing a complex language here--just something which everyone on the
planet should be able to make without much trouble--a web page. As I
mentioned, I've seen first hand how easily children can get started on
it, and they, as beginners, were not at all dismissive of being able to
use their native language, nor were the adults I spoke with here at all
opposed to the idea (on the contrary, they liked it) unless again it
would become a crutch (though I really think the opposite would be the
case--it could well spark more interest in programming as a whole).
Given the possibilities for browsers to handle localized XML natively,
for translation to be done automatically (and stylesheets are cached
anyways), and optionally in conjunction with a free, server-side
conversion service, etc., there really wouldn't be much to deter such a
thing from working.\
Brett
