[SML] Internationalization. (Preliminary EBNF for SML)

[Paul Tchistopolskii]

I agree with Rick that  this area is actualy 
*very* tricky.

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 
be: 

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.

Rgds.Paul.

----- 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
> >think. 
> 
> 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
> it.
> 
> 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;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)