HDTenEightyP/NetNews huggingface dataset:
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 2 Jan 93 01:41:14 GMT
Organization: CWI, Amsterdam

In article <1i2ommINN5uh@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
 > In article <DwqPwB3w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:
 > >> defined rules for cross-sorting (unlike latters WITHIN one
 > >> meta-alphabet; you CAN sort English and German words together
 > >> and it still will make sense; 
 > >
 > >Why do you think it would make sense?
 > 
 > It's easy, Watson. Names, for example. Or (a case from my practice)
 > -- there is a lot of commercial enterprises in Moscow with English
 > names (moda, i guess). Then, i've got to sort the list.
 > The KOI-8 sorting produced a list contained all Russian names
 > in alphabetical order and then all English in alpabetical order
 > which was exactly what was desired.

You are confused about a few things.  Unicode will help your sorting
Cyrillic names and Latin names just fine.  It has separate coding points
for the complete Cyrillic alphabet.  You are mixing soring with different
scripts and sorting different languages.  The latter makes no sense if
you use for each word the place it should occupy in its native language
(especially for loan-words).
 > 
 > >It won't make sense. Lexical sorting makes only sense, if at all, in
 > >*one* single language.
 > 
 > See before.
See before, you give different scripts not different languages.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.std.internat
Subject: Language tagging
From: djbpitt+@pitt.edu (David J Birnbaum)
Date: 2 Jan 93 17:29:57 GMT
Organization: University of Pittsburgh
Keywords: ISO10646 Unicode

>Just the input problem is enough to kill this idea, I think: The user
>would have to get the language of every character he types correct,
>and as somebody who routinely (as in usually large amounts every day)
>enters text in several languages (English, Swedish, and Finnish, with
>a few quoted words every now and then from a number of other
>languages, including German, Latin, and French) and often enough mixes
>several languages in one sentence, let me tell you that it is _not_
>going to succeed.  Having to switch language mode every few words, or
>for every different document, is not going a workable solution.

As is readily acknowledged by the UTC, Unicode encodes scripts, not
languages, which means that language-dependent information must be added
separately if language-dependent operations are to be performed. As has
been noted in this forum, language tagging does not solve all locale
problems, since (for example) sorting may follow different rules in
different locales within a single language.

I think the objections to the input-related problems of Vadim's proposal
are misdirected, since both Vadim's proposal and Unicode require the
user to input language identifying information during data entry if this
information will be needed for later processing. Under Vadim's
proposal, what would be input would be an instruction (not part of the
stored text stream) to shift to the appropriate subset of characters.
Under a system built on a Unicode character set, what would be input
would be some sort of language or locale tagging that would be entered
into the text at a higher level than character set.

In both cases, if you want language-specific data in your text stream,
you have to say so during input. If I need to insert Bulgarian words
into a Russian text stream I can do so without indicating a change,
as long as I understand that the consequence will be that the Bulgarian
data will be treated like Russian.

The difference between Vadim's proposal and Unicode, then, is not one of
input, but one of encoding levels; Vadim wants the language information
to be part of the character set, while Unicode puts it at a different
level. Regardless of which side one takes in this disagreement, the
user at the keyboard has to input "Finnish" or "German" or whatever if
he wants Finnish data to be treated differently from German data.

--David
--
-- 
Professor David J. Birnbaum         djbpitt+@pitt.edu [Internet]
The Royal York Apartments, #802     djbpitt@pittvms   [Bitnet]
3955 Bigelow Boulevard              voice: 1-412-687-4653
Pittsburgh, PA  15213  USA          fax:   1-412-624-9714
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Re: Data tagging (was: 8-bit representation, plus an X problem)
Date: 27 Dec 92 17:58:37 GMT
Organization: Tokyo Institute of Technology

In article <24479@alice.att.com>
	andrew@alice.att.com (Andrew Hume) writes:

>	however, as i hinted and perhaps should have emphasised,
>plan 9 does not address i18n as such. although support for large
>or alternate characters is a prerequisite to i18n, you need a bunch more.

Surely.

>Locales, in this sense, are a complete and utter mistake.
>don't misunderstand me, they are totally wrong as well.

I agree with you.

>	the more insidious problem is that a bunch of the locale functionality
>(and certainly most of the stuff about language and scripts) is
>bound tightly to the data, and not to the processing of it. for example,
>japanese better get rendered as japanese no matter what your locale is.

I heard that, microsoft's NT will have a locale mechanism so that
it can print Japanes Han as Japanese and Chinese Han as Chinese,
which is impossible with bare 10646/Unicode.

Then, how can we have a file containing both Japanese and Chinese?

>another example is the issue of system error messages; what language
>(for example) should they be in?

>customer satisfaction is high
>until the first time someone attaches a file server with dutch language
>errors, follows a sym link through a file server attached with french
>messages, and the file doesn't exist.

Shouldn't we use error numbers internally and interprete it by local
programs?

							Masataka Ohta
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 1 Jan 1993 16:43:55 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages

In article <8494@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>As somebody else mentioned already: should a spelling-checker allow a
>German A-umlaut in a Swedish word?

No, it should not. As well as it should not allow similarly-looking
hierogliphs of mumbo-jumbo tribe. Think of that as of different letters
which happened to look remarkably alike -- like I and l. Moreover indroducing
foreighn letgter in a middle of a word requires deliberate action and in practice
is real seldom occurence (i have a keyboard with Cyrillic with a lot
of similar-looking letters - o, e, k, x, c, m, E, T, O, p, P, A, D, H, K,
X, C, B, M with TWO codes in KOI-8) -- ever saw it in my postings here?
And i do not use spell-checkers.

>If so, what are the consequences,

The good spell-checker will suggest to replace the letter with the
correct one.

>Moreover, one question: how would you encode the German A-umlaut such that
>it sorts properly (i.e. as if it is the letter combination AE)?

The sorting order should be strict -- if you have two identical words
with a-umlaut and ae in the middle is it the same word? If it is then
ae IS a variation of a-umlaut and should always be treated as a signle
letter.

>Even in
>a single language (German) you can not come up with a coding that gives
>proper sorting. 

You can come with a reasonable approximation anyway.

>And also how to code the German eszet such that when
>uppercased it becomes the *two* letters 'SS' (and how do you lowercase
>that again?  Things are not as simple as you appear to think.

Then there is an uppercase eszet which looks like SS. An input program
will map the keyboard accordingly.

Forget about "traditions" -- users do not care which code is inside if
it looks like their usual stuff.

Basically it is a purely mathematical problem -- you've got a number
of orderings and map it into single (partial) ordering by merging
as much as possible elements. The number of meta-alphabets is generally
determined by the criteria of minimality of duplication.

--vadim
From: andersa@Riga.DoCS.UU.SE (Anders Andersson)
Newsgroups: comp.std.internat
Subject: Meaning of 'locale' (was: Data tagging)
Date: 29 Dec 1992 01:47:09 GMT
Organization: Uppsala University, Sweden
Distribution: world
NNTP-Posting-Host: riga.docs.uu.se

In article <24479@alice.att.com>, andrew@alice.att.com (Andrew Hume) writes:
> 	i feel obliged to give an example. locales seem to have an
> underlying model that a user doing processing is doing that processing
> in some local context (locale) with a number of conventions and rules
> governing that processing. if this was all that happened, we'd be in
> good shape. but hey, what about networking? there are two problems
> here. one is almost trivial; suddenly ``local'' is undefined.
> if i'm in berlin and rlogin to paris, which locale should i use?

While I agree completely that the 'locale' is an insufficient
solution, I don't think we even need actual networking (in the
sense of real-time connectivity) to see the effects of this.
Problems arise as soon as data from different places end up in
your machine.  As I assume you didn't create your own software
environment from scratch, you'll probably have a blend of many
ingredients; your vendor's files mixed with your own and more.

Your personally selected locale may often be the right choice,
but not always.  Should files written on a distribution medium
in Massachusetts half a year ago appear with timestamps in Eastern
Time or MET when listed on my machine in Europe?  Having more than
one user on my system is enough to introduce a lot of new problems:
These users may have different native languages, and thus pick
their locale accordingly.  In case some application they run
generate error messages that, in addition to being displayed to the
user, are sent to syslog for the record, should the centrally stored
messages be in any particular language?

So, I don't think the potential argument "non-networked computers
don't need that much L10N" is too important.  In a sense, all
computers are part of a network where humans provide the links in
the absence of TCP/IP and optical fibers.  Since the solution needs
to be invented anyway, it would be a bad idea to split the market
between 'networked' and 'non-networked' systems already at the
design stage, and only provide the L10N solution to the former.
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 325, S-751 05 UPPSALA, Sweden
Phone: +46 18 183170   EMail: andersa@DoCS.UU.SE
From: andersa@Riga.DoCS.UU.SE (Anders Andersson)
Newsgroups: comp.std.internat
Subject: Re: An alternative I18N paradigm
Date: 28 Dec 92 17:17:53 GMT
Organization: Uppsala University, Sweden
NNTP-Posting-Host: riga.docs.uu.se

In article <1hkff3EINN5uv@uni-erlangen.de>, unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) writes:
> I suggest that this international local should use existing ISO standards
> where possible. Some conventions for this international locale might be
> 
>   - use the metric system (SI units)
>   - use ISO paper sizes (e.g. A4, C5, ...)
[lines deleted]
>   - ... (additional suggestions are welcome)

  - a unified currency (say, the ECU)
  - a single natural language (say, English)

> This solution for internationalization is so simple that I wonder, why
> still so many people are working on much more complicated systems that
> will never give a perfect solution.

Some people believe that computers should be made to fit the needs
of humans, not the other way around.  As a programmer, I prefer
array indices originating at 0 rather than 1.  To a non-programmer,
this is strange and unintuitive, and I'd never suggest that house
numbers should start at 0 just to simplify the implementation of my
mail-delivering robot for the postal services.

Likewise, if we really want native speakers of Buginese to use
natural language to communicate with computers, then we should
provide them with Buginese-speaking computers, rather than telling
them to learn computer language (English or whatever).

While patiently waiting for the ultimate solution, we'll have to
stick to what's available, i.e. software that is heavily US-oriented,
and heavily computer-oriented.  Enforcing yet another artificial
standard to replace what is popular use only serves to make people
equally miserable.  If they adopt one voluntarily, fine.
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 325, S-751 05 UPPSALA, Sweden
Phone: +46 18 183170   EMail: andersa@DoCS.UU.SE
Newsgroups: comp.std.internat,soc.culture.nordic,soc.culture.german,soc.culture.french,alt.folklore.computers,news.future,news.admin.misc
From: ddawson@mothra.syr.EDU (Dick Dawson)
Subject: Re: 8-bit news
Organization: Syracuse University, Syracuse, NY
Date: Sun, 3 Jan 93 01:35:54 EST

In article <1992Dec14.161106.8111@klaava.Helsinki.FI> olounela@klaava.Helsinki.FI (Olli Lounela) writes:
>In article <1gi57dEINN2p7@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes:
>>Since MS-DOS 3.3, each PC has a code page 850 supported by it's DOS.
>>This code page contains ALL Latin 1 characters (that was the reason, why
>>it has been introduced), but with other codes than in ISO 8859-1, in order to
>>stay compatible with the old traditional IBM PC code page 437 which is
>>supported in hardware by even every CGA card.
>
>This is true.  However, a sad fact is that not all programs understand
>about code pages, a most notable example being dBase IV.  Thus, I've
>been forced (well, almost anyway :-) to use page 437 and stomp all
>country specificisms onto it.  No, I'm not going into specifics, just to
>spare you from the horrors. 
>
>(Yes, I am a CP maintenance person, and getting more and more severe
>symptoms all the time...)
>
>-- 
>	Olli, 3 dan
>
>E-mail: olounela@cc.helsinki.fi           ! .sig still under construction.
>Blame me only for any opinions expressed. !  Never you mind, I don't either.


Further problem: I haven't found any way to get to any useful code
pages from any application, esp where needed, eg: in a text editor. 
Sure, I can re install moststupiddos for another country.  Therefore
trashing my whole file system.  What I need is a switch on the fly
system, or, better, European characters available at any time by some
simple key combination.

Any help available?

No moststupidwindows please.

Dick   ddawson@mailbox.syr.edu
Newsgroups: comp.std.internat
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: Re: What are the ISO paper sizes? (Was: An alternative I18N paradigm)
Date: 31 Dec 1992 23:36:36 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de

cline@cs.scarolina.edu (Ernest Cline) writes:

>|  - use ISO paper sizes (e.g. A4, C5, ...)

>However, what I would like to know is what size is A4 or C5 or the rest
>of these map references that ISO uses for paper.

As far as I know, these paper sizes are not only used by ISO, but by nearly
all countries on this world apart from North America and Japan.

The standard defines 3 geometric recurrencies of paper sizes: A, B and C.

All basic ISO sizes have a ratio of 1 : sqrt(2). This is the only format
with the following property: If you cut a piece of paper parallel to
the shorter side in 2 equal pieces, than you get the format
sqrt(2)/2 : 1 = 1 : sqrt(2). This is VERY useful if you work a lot
with copying machines that allow to zoom 2 pages on one etc.

The A0 format has an area of 1 square meter, A1 is 1/2 m^2, A2 is 1/4 m^2,
A3 is 1/8 m^2, ... and all have the same 1 : sqrt(2) format. The official
format definition is a table with lengths rounded to millimeters and
tolerance boundaries, but this design principle is at least explained
in the DIN standard (written around 1920) from which the ISO standard
has been derived about 20 years ago.

The B series consists of the geometric means between two A papers. This
has been introduced for applications where the steps between the A
papers are too big. The C papers are the geometric average between
an A paper and the next bigger B paper and are normally used for 
envelopes.

There are a few other definitions and perhaps I'll include a full list
of international paper sizes in the next comp.std.misc FAQ.

BTW: As a 10 year old boy, I discovered that all pieces of toilet
paper have the same format in Germany and many other European countries.
So there must have been a standard. I wondered, why they selected exactly
this format and I developped fascinating experiments for finding the
optimal toilet paper standard. And then I discovered, that 4 pieces of
toilet paper have the same format as an A4 paper => German toilet
paper is just A6 format! :-)

Happy new year!!!

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 1 Jan 93 11:54:24 GMT
Organization: Enea Data AB

Vadim Antonov (avg@rodan.UU.NET) writes:
>If a combination of letters is treated as a letter IT IS A LETTER.
>Then add it to the alphabet and let the keyboard driver (which surely
>knows the language -- simply because there are different keyboard
>layouts) to handle the matter.

So if I type a C then a million key presses later changes puts in
an H after the C how can the keyboard driver handle that? It might
not even be the same driver who are seeing the two!

>FYI, English has some compound letters too (though they're used only 
>in typesetting) -- ff, fff, fi, ffi, fl, ffl..

Which is the not the same as Spanish CH or LL. Saying that ff is one
letter is like saying Russian "bI" is two...

>why on the Earth do i need to spare bits for encoding glyphs if
>i already know the language and 8 (or 16 for oriental languages) bits
>is quite enough to map the alphabet. Don't you see this gap in
>the logic nullifying all benefits of 10646?

What the hell has the number of bits to do with anything? Do computers
exist for the programmers of the users?

>With a trivial trick of including several codes for identical glyphs
>for letters from different languages you can put all of them in ONE
>meta-alphabet.

Well that's is already done in 10646 for letters which are the same in
Latin, Cyrillic and Greek scripts. Hopefully, that will not cause to
much of a mess.

But what Vadim Antonov was discussing was including identical glyphs
for languages like Swedish, German etc. I guess people are in for real
surprises because things don't end up where they expect them because 
they happen to use the wrong type of dotted A. Not talking about the 
confusion they get when they are searching the text. Possibly this
arrangement is friendly for the the lazy programmer Vadim Antonov, 
but not for the poor user.

>ASCII is for English, period.
>...
>The semantic in ASCII is hard-coded -- it is the order of letters
>and the trivial upper-case to lower-case convertion.
>Unfortunately the move to abolish the last traces of semantic and
>make it PURELY graphical format destroyed the usefulness of such
>encoding for data processing.

In what way is ASCII, which is - as state yourself - for English,
useful for data processing in German or French? Or even its
semantics useful for these languages? In the poor variety of
English you can render with ASCII, sorting can be based simply
on the letter ordering, because accents, digraphs and diaeresis
which only occurs occassionaly were left out. But German and
French cannot be simplified in this ways because umlauts and
accents appear much more often. For these languages the sorting
algorithm must be more complex that simple sorting on collation
order, so what's the use of a hard-coded semantics a la ASCII?

You are seeing the solution, simple bit-order comparisons. But
unfortunately there are not many problems which have this solution.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Jag gav en k{ck tjeck en check.
From: bygg@sunet.se (Johnny Eriksson)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 3 Jan 93 14:44:56 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <VyqRwB2w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:
>avg@rodan.UU.NET (Vadim Antonov) writes:

 [Much material omitted]

>> It is also inadequate for cyrillic-based languages (slavic and
>> others; not all slavic languages use cyrillic and most of
>> Cyrillic languages aren't slavic!)
>
>I believe you, but what's the problem with UniCode here?
>Maybe you should tell me more about KOI-8 (by email, please).

Why not tell everyone about KOI-8 and the other cyrillic coding methods,
code tables, design principles, whatever.  There may be more than one
of us that are interested in that information.

Vadim, please?

--Johnny
From: tt@tarzan.jyu.fi (Tapani Tarvainen)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 2 Jan 93 16:08:58 GMT
	<8498@charon.cwi.nl>
Organization: University of Jyvaskyla
Originator: tt@tarzan.math.jyu.fi

In article <8498@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:

> I would like to be able to set an environment
>variable in my profile that my preferred language is Dutch.

This is the approach taken by HP (I don't know if it was their idea or
from POSIX or whatever): simply set the environment variable LANG as
"dutch", "finnish" &c, and lo!, sort, globbing, &c begin to work as
they should in the specified language.

(There are some bugs yet, and in fact I have to set LANG as
"finnish.iso88591" as there's also the HP Roman-8 character set, but
the idea is right, IMHO.)
--
Tapani Tarvainen  (tt@math.jyu.fi, tarvainen@finjyu.bitnet)
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Pointer comparisons
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 21 Dec 1992 12:50:09 GMT

sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:

>In article <BzDs2x.wA@frumious.uucp> uunet.ca!frumious!pat writes:
>>
>>   Two pointers to the same object compare equal.  If two pointers
>
>...but nowhere do I see a statement that (p == q) ==> p and q point
>to the same object, even if p and q are the same type.

This is apparently an oversight, an unintend omission.
The ANSI C standard includes such a guarantee, so I am told,
so C compatability requires that this hold at least for C++ objects
that are also C objects. (Though it needn't apply for empty
structs/classes, for example, since C doesn't allow empty structs.)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.std.c++