ANSI CL is also lacking in support for printing the new Euro notes on
  ordinary office laser printers, another would-be useful thing that is
  outside the scope of the standard.

  If you have actually tried using locales to achieve localizability and
  still think they serve a useful purpose beyond marketing rhetoric, I
  would like to see your code.

| So any non-Latin-1 user [...]

  ANSI Common Lisp is not even defined for ISO Latin 1, but for a character
  set that closely matches ASCII or ISO 646 IRV.  However, that is only a
  minimum requirement -- the implementation is obliged to document what it
  actually supports.  Several Common Lisp implementations support a 16-bit
  Unicode.  Note that there is no standard way to add case information to
  the supported character set, so if you want to depend on the language
  support for case conversion, you are SOOL if what you want it is not
  supported, especially if the char-up/downcase functions are inlined as
  tests for a-z so you cannot even redefine them.  (E.g., this is still a
  problem in Allegro CL's 8-bit-character version despite excellent support
  for character sets in the 16-bit-character version.)

| And when I think about some funny features in the language like
| YES-OR-NO-P or ~R in FORMAT, I understand that they were designed with
| English taken in consideration only.

  This is a good thing.  If it were designed by the usual "international"
  tactics, it would lack a lot of useful features because some rinkydink
  language with a few hundred speakers could not support it, like plurals.

  The fact that you react to these things with some hosility is a good sign
  that Common Lisp would have suffered had it been intended to placate all
  the sourpusses in the world who envy the United States is position and
  who loathe the role that English has acquired -- instead of French or
  German, both or either which "deserve" it much more than English does, if
  you poll several large segments of the European population.

  Fortunately, I can say all these things because I am _not_ American, but
  happen to come from and live in a rinkydink country with three official
  languages for less than 5 million people, one of which is a pathetic
  rural rebellion against national standards set by the cities and which
  today differ much less than British and American English.  Just how hard
  do you have to lose to think such a stunt is a good idea for the _same_
  people?  Right!  So pardon me while I think "locales" and supporting
  loser dialects is a Bad Idea.

So I think _I_ could certainly live with computer programs that only
support English as language...

ciao,
Jochen

  Fixing yes-or-no-p in the locale is the wrong place to do it.  This is
  clearly a user-interface function that depends on a particular mode of
  user interaction with specific programmer and user expectations.  Making
  it more general is a mistake.  A more elaborate user interface would need
  more than just yes-or-no-p and y-or-n-p.  _If_ these functions match the
  user interface needs, they will be used, and then all parties involved
  expect them to be exactly as they were when they got into the language.
  If they are not satisfactory for user interaction, some other functions
  will be written and used in their place.  Please do not bother making
  "localized" versions of these functions.

  I work in two languages all the time -- have been since I were a kid, and
  I consider myself fluent in both.  I am constantly deeply annoyed by the
  incompetence of the fools who think they can translate movies and books,
  and can only imagine what kind of mistakes are made in translations of
  languages I cannot read in the original.  Not many years ago, fluency in
  several European languages were common among academics and the lingua
  franca (!) was Latin _long_ after that language had ceased to be spoken.
  It is somewhat unfortunate that computer science uses a living language
  for its lingua franca, in contrast to law and medicine, which are both
  firmly based in much older languages and cultures, because that makes a
  lot of people who fail to grasp the function of a common language think
  it is a natural language and can be replaced by another, particularly
  those who speak it naturally and are overcome with political correctness
  and think they should be guilty of the fact that historic accidents
  favored their language.  The common language is, however, _not_ a natural
  language except by accident, and it cannot be replaced by another natural
  language without replacing the whole culture with it.  Those who think
  _their_ natural language should be the common language should just get
  over their egoistic provincialism and learn to deal with reality.

  And speaking as a user of Norwegian software, I do not accept some
  two-bit "translation".  If I have to translate the incompetent Norwegian
  back to what I think the natural English would have been in order to
  understand what the Norwegian probably means, all parties involved would
  have been better off with the original.  Like the other day, I saw "IP
  header compression" translated on a cell phone to what best translates
  back to "reduced headlines".  I think translation between English and
  Norwegian is important enough that I contribute to dictionaries and try
  to help companies who pay their translators basically nothing to write
  the local version of text that somebody else paid a large sum of money to
  get just right in English.  Thankfully, however, original-language
  paperbacks in British and American English are now outselling translated
  versions, and several major film releases are available in original
  versions, so there is hope for this undersized country.  English is now
  taught from the first grade.

  The more I have worked with software in these two different languages,
  the more I am convinced that message catalogs is one of the worst
  non-solutions.  It works OK only if you have a primary language and
  subordinate languages that you do not care if suffer from stilted
  expression and phony flow of logic.  We have to realize that the logic
  flow of the primary language is deeply engrained in the program itself
  and that "translating" what appears to be a step-by-step procedure in one
  language may require fewer or more steps and with a different order in
  another language, like in which order you provide the components of your
  name and postal address, etc.  The whole user interface/experience needs
  to be tailored to each culture and language.  "Translation" must be done
  by programming.

  This naturally leads to the conclusion that software should not speak
  natural languages to users, but formalized protocols to user interface
  engines.  In other words, yes-or-no-p would be a protocol element, not a
  _specific_ user interaction in my view.

  Well, you cannot write a program that works in English, Spanish, French,
  Arabic, Chinese and Japanese unless you know _all_ these languages and
  _prepare_ for the translation.

  The only way to make a program work in more than one language is to make
  it work in _none_: formalize a protocol and write user-interface front-
  ends to it.  Let those who understand the application _and_ the target
  language write that user-interface front-end.

  English happens to be the _common_ language of the field of computer
  science.  It no longer has the role of a natural language in computer
  science.  That this leaves a large number of people "handicapped" by
  being misled to believe that _their_ language is the common language, is
  nothing but unfortunate.

  Forget the whole locale business and write software that speaks about
  objects and units and internal stuff, and let several user-interface guys
  handle the user-interface portion that talks to people in various
  cultures.  This is not hard at all, once you get past the misguided
  notion that all computer programs should talk directly to users.

# So pardon me while I think "locales" and supporting loser dialects
# is a Bad Idea.

Only an arrogant moron, living in a loser country could utter such loser
sentences. If that half brain that this lower life has rented were still
half working [we're talking 25% of full regime here, if you can't do the
math yourself] we would be spared such loser posts which don't bring any
value _at all_ to that thread.

  Jochen Schmidt

# My English is far from being good, but I finally came to the opinion
# that I don't see German the language as very important.

I would agree too...if my native language were German that is ;-)

It turns out that my English is far better, and that my French is near
perfection. If I had more time, I would certainly learn more winner
languages (Russian and Arabic spring to mind).

# More and more often I catch me that I at least partially think
# in English

No you don't. Only mono-linguists can argue they do, until proven wrong.

When you utter some sentence (in any language) you know, ahead of the
words coming out of your mouth, what the sentence is going to affirm.
(that is, unless you are a politician of course ;-). Yet those words
that will appear in the near future, are not _verbalized_ yet, and are
only _translated_ to your utterance language as your tongue makes some
progress.

While, according to Bergson, the language is the support of the thought,
it is _not_ the thought itself, even though a given language _shapes_ the
way you think.

Multiplying the languages you know can only give you more perspectives,
and ways of thinking. Reducing their number can only lead you to an
impoverished mental landscape, where entire areas of human thought will
simply never flourish.

Finally, this idea that a given language has "won" is utter non-sense.
French had "won" two centuries ago. Where is it today? Give me a break
and go by some more brain cells. At any point in time, there is a dominant
language. Latin two thousand years ago, Chinese in the next decade. And
so what?

So what?

The issue is that way too often, this kind of decision (whether and how
to support non dominant languages) is left to computer specialists, the
vast majority of whom are _anything else_ illiterate. This includes art,
poetry, literature, and most forms of human expressions that do not appeal
to those "computer morons".

If a shoe helps you walk, a computer is meant to help you think. No matter
what uneducated, university degrees loaded psychopaths would love you to
believe.

"Ouf! Depuis le temps que j'attendais ça, je me suis payé le Naggum!"

  Each field has only one common language.  Any attempt to add more will
  split the field.  It is already a problem that research published in
  French and German are unavailable to the rest of the computer science
  community.

| Whether non-native-English speakers (or more importantly, whether
| non-English speakers) accept English-only interfaces is going to be up to
| you/them.

  Fluency in English is a sine qua non in computer science.  Programmers
  who want translated software tools and programming languages in their
  native tongue will forever remain incompetent tinkerers.  Only one
  company on the planet thinks this is a good idea.

| And the acceptability of such English-only interfaces are likely to vary
| according to the audience; whether to the programmer or to the end-user.

  End-users should _obviously_ be served with natural language interfaces.
  I do not see how what I have said could be construed to have been arguing
  against natural-language end-user interfaces.  Quite the contrary, I have
  made several points about how software that needs to talk to real users
  must be tailor-made in each language.  How could this possibly be taken
  to mean that we should _not_ make natural-language interfaces for users?

  What an _interesting_ display of personality problems.  Get help, OK?

So, I think, YES-OR-NO-P in its current state is not very useful in any
program which intended for non-English user, who works with non-English
keyboard mainly. IMHO it is not convinient, at least, because such user
need to switch the keyboard to English and back every time he/she need
reply on YES-OR-NO-P query. It is, of course, is not a problem, because
such functionality can be implemented very easy. It is just a little
inconvenience.

If we spoke about an implementation of "international" functionality of ~R
directive, I would try to offer a some leverage with ability to pass a
list of user arguments to ~R that then could be passed to some callback
function (that could be set by a programmer) to get a proper form for ordinal
number.

Again, I don't speak that this functionality is needed. I think this
is just some convenient tools in the language. If they were absent, nobody
told about them. But, on the other hand, if they were added, why didn't they
have done more extendable?

The more important thing is, of course from my point of view, ability to
set a proper charset.  Without that functions for manipulating strings and
characters don't work properly. So STRING-UPCASE for example doesn't not
work with Russian in Lispwork 4.1.20 Personal Edition, CMUCL. There is
SET-LOCALE function in Lispwork but only "C", "POSIX" and "*.ISO-8859-1"
locales exist. If my memory serves me, there are same situation in Allegro
6.x (i.e. SETLOCALE exists but number of localies is limited by
C/POSIX/*.ISO-8859-1)? But because I don't have Allegro on my computer
now, I can make a mistake here.

Again, It might be not a problem but just a little inconvenience.
Because, I suspect that correspondent localies can be added to both
Lispwork and Allegro. And it is not a very hard ever for such a beginner
as me to implement a basic SETLOCALE functionality in CMUCL using existing
Alien interface.  

I don't blame anybody or anything. I think that a great job was done with
the standard. I can understand vendors who probably have had most of their
customers in English-spoken countries. So there were not value reasons for
them to harry up with implementation of functionality that was not part of
the standard.

Thank you and all others senders who reply on my message. I have been
reading this newsgroup regulary enough and I have never seen before a
discussion of that topic. But these little problems with locales were the
one of the first thing which I had encountered at the very begining of my
CL voyage. :) I sent my message driven by intention just to attract
community's attention to this topic, but didn't blame anybody.  

Languages and the corresponding cultures are tightly coupled - therefore I
choose languages of cultures that I find interesting. Until now my plans
for the next language I want to learn as soon as I find the time are either
Chinese (Mandarin) or Japanese.
I furthermore think that it is common to learn the language of the country
were you live - regardless if the country is a "winner" or if the people
speak a "winner language".
There is only one country in Europe that demands from other countries to
learn their native language at the european parliament (and it is not
Germany).
I'm quite happy that those ugly nationalistic attitudes widely disappeared
in Germany many years ago...

Grow up...

ciao,
Jochen Schmidt

First, you are failing to distinguish, as I asked you do, things that the
language keeps from happening from things the language merely does not
force to happen.  The language definition does not say an implementation
should not do this.  HOWEVER, if the language definition *did* do this,
it would be a weaker language.  You appear to be assuming (in both cases
incorrectly) BOTH that (1) YES-OR-NO-P cannot accept such responses now
and (2) YES-OR-NO-P works by textual typein.  As to point 1, a conforming,
correctly localized implementation of Lisp, is already permitted to do what
you say.  That is, what stands between you and success is not the language
definition but your vendor's choice of how to render the language spec into
a language implementation.  But as to point 2, some vendors work by asking
a textual query in which "yes" or "da" might be 'yes' answers *already*
and "no" or "nyet" might be 'no' answers *already*.  Now, if the language
required so simple an interface as you provide, *yes-reply* could only
contain one value, not many, and so you'd be eliminating valid replies.
At minimum, you'd want a list of yes replies.  But then in that case, the
implementations where it was a dialog would not know what to do.  In that
case, how would you distinguish between whether (yes-or-no-p "Exit?")
and (yes-or-no-p "Salir?")  producing:

    Exit?                  Salir?
                  vs    
  [Yes] [No]             [Si'] [No]

   (english)               (spanish)

The heuristic guessing of language (especially based on a small number of
letters) would be impossible to do reliably.  Certainly it would not be
able to tell whether to do even something like:

   Comer?                  Comer?
                  vs
  [Si'] [No]            [Sim] [Na~o]

   (spanish)             (portuguese)

much less someting like this :) ...

     42?                                42?
                         vs
  [Yes] [No]                     [HIja']  [ghobe']

  (federation standard)               (klingon)

The thing to understand is that these are *interface* issues and that such
issues are explicitly not something that Common Lisp seeks to address in the
base level of its standard.  These were left to vendors and were
intended to be the subject of separated (perhaps layered) standards.  They
are INAPPROPRIATE to standardize in a context where the space of interface
concerns cannot be known because each such interface concern creates a nuance
that cannot, a priori, be known.

In the future, there will also be voice and visual gesture interfaces,
and CL does not address those either.  If you have Star Trek movies
over there, think of YES-OR-NO-P as an antique interface, like Scotty
uses in Star Trek IV, to talk to the bootstrap version of a system, in
order to get it into application mode where other interfaces, not
defined by the base layer, are available.  It is IMPORTANT that Common Lisp
does not pretend to address those other layers because it will SURELY FAIL
to do them right and may trick implementors into thinking it has an answer
that works, when it does not... just as you have already been tricked into
thinking that YES-OR-NO-P is ever going to be the answer to the kinds of
issues you are raising.

I say again:  The correct solution to this problem is simply to IGNORE the
presence of YES-OR-NO-P except for simple applications written in "federation
standard" (i.e., English), the like-it-or-not interchange language of the
modern world.

And before considering Russian, consider even the simple mess that the
British and the Americans don't entirely agree on the meaning of the "English"
word "billion" so that detecting whether an error has occurred is
extraordinarily hard if you ever even hint that ~R's purpose might be
to satisfy localization constraints.

There may even have been some US-bias in the design.  For that I
apologize.  But in fairness, the US *did* design the language and our
culture is, I think, due some small historical accomodation to keeping
its programs running while stretching to embrace the new global
market.  It's not like the present definition of ~R really breaks existing
programs when compiled in Russian.  Existing programs were ALREADY broken
because they do things like:  (write-string "Hello World") instead of
                _                  _
(write-string "| |p|/|BeT M|/|pOBo| O"), even without worrying about what

the world is going to say in response.  [Sorry about the character set
problem there. And I hope I didn't say anything offensive--I was just
working from online phrasebooks. :-]

  Why, then, did you write the call to that function in the first place?

  I see another case of blaming the language for failing to be convenient
  _enough_ and trying to blame some cultural artifact that the _programmer_
  has not been able to figure out is not going to do what he wants.

  It is great that Common Lisp is usable by us "furriners", but when I was
  faced with the inability of Allegro CL 4.3 to deal with case issues in
  ISO 8859-1, I spent some time fixing this problem locally, and repeated
  this for Allegro CL 5.0 so it would work in my application, which used
  and required ISO 8859-1 to work properly.  It was not particularly hard.
  However, I did not attempt to make format control ~P work for Norwegian.
  I did not use yes-or-no-p in the Norwegian user interface.  I did not
  expect a language I have learned and studied suddenly to become plastic
  and turn into something it is not just because I wished for it.

  I actually find it completely incredulous that otherwise seemingly smart
  programmers suddenly get a case of "wishful thinking syndrome" and fail
  to understand that a programming language is what it is.  If the language
  does not fulfull your childhood dreams, at least try to figure out if it
  is actually blocking you from realizing them _with_ it.  If so, drop it
  and find another language that does not block your dreams.  If, however,
  the language just falls short of some egoistic "ideal" that you think you
  have right to complain that the world does not fulfull for you, you have
  a _much_ bigger problem than the failure of yes-or-no-p to speak Russian.

  Programming is about making new things possible, about realizing dreams,
  about _creating_ dreams.  I get so fucking _tired_ of the whining losers
  who expect languages and environments and computers in general to relieve
  them of having to exert any effort at all to get what they want, and who
  get _sore_ when the languages refuse to do their bidding.  Sore losers
  who fail to grasp that they world does not owe them a thing come out as
  exceptionally demanding assholes who cannot tolerate that they have to do
  some of the work themselves.

  Common Lisp is one of the languages in the world that offer programmers
  _so_ much for free already, but what happens?  Again and again, whining
  losers gang up on it for not offering them enough.  Even thinking about
  making something useful on their own instead of whining is beyond these
  people, so it is all fault-finding instead of doing something new and
  useful.  This is probably the biggest difference between the Common Lisp
  community and the Perl community: Give people a shitty language and they
  expect nothing, so create what they need, but give people a great
  language and they expect everything, so only pine for what they miss.

  Internationalization and _real_ localization is very hard work.  It is
  not something you tack on as an afterthought, any more than security and
  qualit is.  If some standard function named yes-or-no-p does not satisfy
  a Russian user, the only surprise should be that someone could even come
  up with the idea that it should have.

  If you have a problem with missing functionality in a programming
  environment, there is actually a name for the solution to your problem:
  It is called _programming_.

However, are you saying that a "y" in one language is the same as the
equivalent "n" of another language?  This would be consistent with your
statement that multiple-languages would need to be acceptible as
input.  (I happen to disagree with this; it violates rules of least
surprise - if I accidentally hit the "s" key and that got accepted as
"yes" (via "si") then I would become pretty angry at such suprising
behavior).

The above paragraph is not intended to refute or question a claim of _use_
of English in computer science, but only a need for _fluency_ in it.
All of our customers use "cdr" and "cons" just like the rest of us (are those
English words? :-), and the real problem is in communicating the programming
concepts within the communities within which these programmers are
operating.  If a Japanese programmer decides to name a function with Kanji
characters, do we force him to translate the name to English in order to
help him solve a bug?  The question is not rhetorical; every vendor has to
answer it for themselves.  If the answer is "yes", then some of that market
is shut out.  If the answer is "no", then the vendor must learn at least
the characterset of the customer's language.  We chose the "no" answer.

So the real point of issue is within this center of the spectrum, where
we might ask the question "How much do we require the average programmer
to know English in order to program in Common Lisp?"  I think that the
current answer is "They must know English", but I think also that it
_should_ be the case that "They need not know English, only Common Lisp".

Why would attacking Naggum be _interesting_ ? To whom ?

If attacking Naggum only came from the "bile-overflow" department, then
people may sympathise, but then simply move on. Is Naggum such an important
<plug-some-emphatic-title> that the whole 21st century has to be grateful
forever for having been blessed by the smallest Naggum thought?

  | Naggun standard canned reply to this is going to be along the
  | lines that _I_ need medical treatment because _I_'m exposing
  | personality disorders. And saying <whatever, your-call> about
  | him is simply a sign of me being <brain-under-powered> or whatever
  | he fancies those days.
  |
  | Isn't this entire Naggum-thing pathetic?

Naggum, of all your posts, about 10% have real value. And I mean _real_.
Unfortunatenly, the other 90% is utter non-sense, bullshitting arrogance
of the clever among the cleverest who deigns blessing the poor crowd
with his infinite wisdom.

Naggum, enough is too much. There are real contributors to c.l.l, and
your signal/noise ratio is way too low. Nobody _cares_ about how you
feel, and whether such sub-population deserves to live/die/flourish/perish
according to St Naggum.

Make us a favor: give us a break: stop posting 10 times a day to c.l.l
(as if you had no other useful work to do). By restraining yourself to
core issues, and avoiding raw, unwarranted, blunt, uncalled-for opinions
you will contribute to making c.l.l a better place.

I, for one, would have happily carried on lurking c.l.l for quite a while
if it werent' for this and the previous message.

I have chosen the latter option since some of St Naggum's posts are
deliciously funny.

You might think that the glyph produced by this character is the
letter c with a diacritical mark under it known as a cedilla.
But on my terminal, it produces a little picture of a donkey.

  "Common Lisp ALLOWS an implementation to provide support for
   international language characters as well as characters used in
   specialized arenas (e.g., mathematics)."

I would think that international standard should REQUIRE such
behaviour, because any vendor now has right don't support
international languages and still claims that his implementation is
conformed with ANSI CL standard. Am I wrong?

(setf *yes-reply* '("Si'" "si'" "s"))
(setf *no-reply* '("No"))
...
(when (yes-or-no-p "Salir?") (exit))
* Salir? (Si'/No) No
...
(setf *yes-reply* '("Yes" "yes" "yep"))
...
(when (yes-or-no-p "Exit?") (exit))
* Exit? (Yes/No) Yes

No need in any heuristics here. Well, only one is needed: which word
from yes/no-replies list do we print in our query. I offer to print
first. :)

or with transliterating with 7-bit ASCII ('i' as in "keep")
(write-string "Privet, Mir!") :)

http://www.franz.com/support/documentation/6.1/doc/iacl.htm#collation-1

I thought locales were an abstraction about the context in which a given
set of characters were to be interpreted, not a representational issue.

Failing to do it thus would, I think, leave you in a serious quandary
about how to deal with a string containing multiple languages in the
same string, such as the hyphenated last name of a person whose parents
are from different (linguistically incompatible) countries.

STRING< and friends are intended to compare strings in a
natural-language-independent way, according to an arbitrary sort order
that is constrained only by the A-Z/0-9 constraints enumerated the
spec.  From an internationalization point of view, this is all
subprimitive and to be ignored.

Proper internationalization would, IN ANOTHER PACKAGE, offer the right
meaning.