Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [SML] Internationalization. (Preliminary EBNF for SML)
 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@a...> > > From: Don Park <donpark@d...> > > >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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
