[SML] Internationalization. (Preliminary EBNF for SML)
paul at qub.com
Sat Nov 27 08:05:01 GMT 1999
I agree with Rick that this area is actualy
Being Russian engeneer I would say that
restricting element names to English in SML
is very reasonable.
But unfortunately, analyzing the ( 5+ years )
experience of multiple 'Cyrillizations' ( and
some other localizations) ( a *lot* of ) - I should
say that for end-user it *is* critical to be able
to use non-English names for elements and
yes - it could be *very* important.
Even the translations of ( for example )
Windows menus to Russian are realy weired
( not because they were done by bad translators.
they were done by *perfect* translators )
and for engeneer it is realy *much* easier to use
not-localized version than localized, but
majority of 'advanced users' including
some engeneers *do* prefer to name their
files and folders in Russian. SML is not a
programming language. It is a framework....
Conclusion. I think the best approach could
1. Only English *elements* ( but 'any' content)
in SML version 1.
2. 'Any' encoding anywhere in SML version 2.
What is 'any' - it's a big question and 'any' in
(1) could be not the same as 'any' in (2).
I think any reasonable design should postpone
some descisions until the basics are tested
in the real life. Postponing some descisions
to SML version 2 may be reasonable, and
multilingual elements look like such a thing.
----- Original Message -----
From: Rick Jelliffe <ricko at allette.com.au>
> From: Don Park <donpark at docuverse.com>
> >The reverse is not true. I dare say that every engineer
> >in the world knows enough English to understand English
> >tag names and attributes names with the aid of readily
> >available dictionary. Ask any foreign engineers if they
> >use names in English or their own language when they name
> >C or C++ identifiers. Ask any foreign engineers if they
> >did not have some English training even before College.
> You would be entirely mistaken in this. Engineers in Africa
> may have French as their second language; engineers from
> ex-Eastern Bloc countries will have Russian as their second language.
> Engineers in China will have Mandarin as their second
> language. And the skills of reading and writing are different:
> many people can recognise English words in context but
> cannot recall them. Asking professional people in America
> if they speak English hardly proves anything.
> And are you saying that SML is a language that only
> engineers should read and write?
> >Internationalization is also less of a problem than you
> This is utterly bogus. Every different language and domain
> area has different problems.
> > Translating English name to foreign words usually
> >results in a weird words. Just ask any foreigner with
> >foreign version of Windows if the menu commands made good
> >sense to them when they first started using it. The fact
> >is that when a person learns how to use computers in non-
> >English speaking countries, they have to learn a whole new
> >set of words consisting of old or uncommon words overloaded
> >with new meanings.
> So we should perpetuate this and make it worse? And it is not
> correct to suggest that a foreign version of Windows has menu
> items that are simply the English words transliterated or directly
> translated. Of course there is a set of meanings of words to learn;
> but why should their be a foreign vocabulary as well?
> >Also, we are going to have a big problem with schema
> >differences in the future and I would rather not have
> >foreign language variations of common tags like <name> and
> ><address> in the pot as well.
> Is this any difference from saying "I don't care how difficult it
> is for losers who find English difficult, as long as it is convenient
> for me?"
> Furthermore, there are many terms that do not have exact
> translations. What is the English equivalent for the Japanese
> address unit "cho"? I helped an accountant at my work
> try to develop standard English translations for payroll
> deduction terms here in Taiwan, and there are many which
> simply are not found in English: without a really complicated
> explaination with multiple English words there is no way
> to give the same markup: looking up words in a dictionary
> is not a productive use of time. Such systems would require
> an extra layer of software to provide UI help, in which case
> the advantage of "simplicity" is lost.
> I agree that it is good to have standard
> terms for common things, and that English is the best choice
> at the moment, but unfortunately not every word exists in
> English and most people in the world do not speak it or read
> Why reduce markup to mere nmemonics rather than be able
> to use names?
> One reason for allowing native language markup is that it
> can enfrachanchise the great proportion of the world who
> are literate but not in English. The goal of markup
> systems should not be to make life easier for programmers,
> but to reduce the requirement for extraneous-to-the-task skills
> as markup is used instead. These extraneous skills should include
> both programming and English-knowledge.
> Rick Jelliffe
> Taipei, Taiwan
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev