=?koi8-r?Q?Thinking_of_locales_=5BSElin=40flagship=2Eru:_=ED=D9=D3=CC=C9?==?koi8-r?Q?_=CF_locale=5D?=

[Fyodor <fygrave@tigerteam.net>]

Hello folks,

Some guy at openbsd@openbsd.ru was pulling out some interesting 
ideas regarding localisation and stuff like that. Per his request
(since I've got some spare time to kill ;-)) I am translating his
message so feel free to share your ideas on the topic:

[ перевод вольный, sorry za netochnosti] :)

---/cut here/--
Hi,

In this message I'd like to bring a couple of thoughts regarding locale
problem in general and OpenBSD in particular. Would like to mention that
I am not going to talk about actual encoding because this side of the problem
is not really a problem (blah blah blah %))

So as we know in OpenBSD (as well as in NetBSD), there are not mechanisms
to implement locale, except for `dummies' which were created for compatibility
reasons. It seems that there's nothing wrong with just porting locale support
from linux or FreeBSD, from the technical point of view it should be rather quick.

The problem is actually following: at the beginning the encoding system
was created considering only single characterset which contains only
alphanum characters, special characters and punctuation.

As soon as computers went out the computer labs, we faced a problem:
operating systems and supplied software was not able to work with
any characters except for the base one. That's how different localisation
methods appeared. Please don't beat me up for generalisation. :) It doesn't
really matter what appeared and when, some interesting ideas showed
up in all those localosation attempts, some of them were developed further:
idea was in replacing second part of the code table with 'localized' characters.
Nice way to work things out, but it brought numerous problems as well:

1. Numerous charactersets (for Russia/CIS there are around 5 different
encodings, if I am not mistaken).
2. postseq. from #1: different encodings are not compatible between each other
and base table.
3. When encoding is lost -- information is lost (rem: I don't get it either :))
4. Add your own ;-)

As the only solution after numerous mutations UNICODE standard has appeared.
So what we have got with that? At least in this system we can univocally associate
a code with any known character (althrough we still don't really know how
to deal with eastern languages, which are based on different principles of
writing characters, some of these languages include up to 50,000 different
symbols, which is a way more than UNICODE allows us to encode (?) and
we can not just drop them).

So what do we get if be base messages in the system on UNICODE? Obviously
we can univocally  encode any character without a fear of loosing information.
That's definetely a positive moment. However we'd have to face several
technical problems as well:

1. How to display numerous symbols from different charactersets simultaneously
or enter them from keyboard? Standard layout doesn't help much if information
is presented in more that 3 different charsets.
The problem with displaying characters could be solved by building not a static
table of symbols, but a dynamic hash-table. Any ideas how to handle keyboard
in this case?

2. Compatibility with current encodings. We can also solve this problem
by creating, by already widely used principle, tables with allocation
of characters which would match existing encodings. By the way we could
use the same method to solve problem with time, currency localisation etc.
So far it's been already standardized however.

3. Base programming language for Unix systems (C) does not have any unicode
support so far.


So far this is only approximate enumeration of problems which could arise
when we try to localize/internationalize(blah?) existing systems. Any comments? :)

I'd appreciate if someone could translate this message and post to misc@ (rem:that's
what I am doing now. A few beers made me useless to do anything else on on the moment :))


With best regards,
Elin Sergey, 

Software Engineer, Protek Flagship LLC
E-mail: SElin@flagship.ru <http://www.protek.com>


-- original follows --


----- Forwarded message from "Elin, Sergey" <SElin@flagship.ru> -----

From: "Elin, Sergey" <SElin@flagship.ru>
Date: Thu, 2 Nov 2000 16:57:48 +0300 
To: "'openbsd@openbsd.ru'" <openbsd@openbsd.ru>
Subject: Мысли о locale
X-Mailer: Internet Mail Service (5.5.2650.21)

Hi

В этом письме я приведу свои соображения по поводу проблемы locale в общем и
в частности в OpenBSD. Сразу хочу оговориться, что, собственно, кодирования
я постараюсь не касаться, так как эта сторона проблемы как раз таки и не
проблема (каламбур %))

Итак, как известно OpenBSD, равно как и NetBSD, не имеют в себе никаких
механизмов работы с locale, если не считать "заглушек", созданных чисто для
совместимости. Казалось бы, что стоит спортировать, например linux
реализацию или FreeBSD... Ничего, с технической стороны, это просто и
быстро. 
Проблема как раз заключается в следущем: изначально система кодирования
символов в системах была спроектирована и создана из расчета на один базовый
набор символов, содержащих только(!) символы латинского алфавита,
специальные символы, знаки препинания и цифры.

Распространение вычислмтельной техники за пределы исследовательских
лабораторий почти сразу породило проблему - операционные системы и
прикладной софт не умели полноценно работать с символами, отличными от
базового. Так появились различные "локализаторы". Прошу не бить за
обобщение. Что за чем появилось и кто это придумал не относится к сути
вопроса. Любопытные идеи по своей сути были заложены в этих локализаторах и
получили дальнейшее подолжение: идея заключалась в подмене малозначимых
символов второй половины базовой таблицы символов на "локализованные"
значения. Красивый выход из положения, но к сожалению, повлекший новый ряд
проблем:
1. Множественной локализации в уровне кодоровок (для России и СНГ существует
5, если не ошибаюсь, кодировок)
2. Как следствае из пп.1  - несовместимость между собой и базовой таблицей
3. Потеря информации при "потере" кодировки.
4. допиши сам %)

Как естественный результат решения подобных проблем в итоге различного рода
мутаций родился стандарт UNICODE. Чем же он хорош? Хотя бы тем что в данной
системе кодирования каждый символ однозначно может закодировать любой из
известных знаков (правдо непонятно что делать с восточными языками,
реализуемыми на совсем других принципах "знакописи", например в некоторых
языках по моим сведениям количество всех иероглифов доходит до 50000 - что
больше даже чем позволяет закодировать UNICODE, а отказаться от них, по
заявлению представителей этих культур нельзя)

Итак, что же будет если в основу сообщений системы положить UNICODE? Вывод
очевиден - мы сможем однозначно закодировать любой символ без бояхни потери
информации, это безусловный плюс =) Однако здесь встает ряд технических
проблем как то:
1. Как отображать множество символов одновременно на экране и вводить с
клавиатуры? Стандартная раскладка здесь мало поможет при случае когда в
информации представлены символы более чем 3 различных этнических групп.
Проблему вывода на экран можно решить построением не статической таблицы
символов, а динамической хэш-таблицы. Есть у кого варианты как быть с
клавой?
2. Совместимость с существующими кодировками. Этого тоже можно добиться,
путем создания по уже широко применяемому принципу таблиц с расположением
символов как в существующих кодировках. Кстати так же можно решить и
проблему с локальным отображением времени, валюты и тп., благо это более
менее стандартизовано =)
3. Базовый язак разработки UNIX-систем (C) не имеет в себе возможностей по
поддержке UNICODE

Итак, вот только примерный ряд возникающих проблем по вопросу локализации и
интернационализации существующих систем. Коментарии?

Я был бы признателен человеку который сможет перевести мое письмо на
английский и отправить его в misc@ =) Было бы интересно послушать их точку
зрения =))

With best regards,
Elin Sergey, 

Software Engineer, Protek Flagship LLC
E-mail: SElin@flagship.ru <http://www.protek.com>


----- End forwarded message -----

-- 
http://www.notlsd.net
PGP fingerprint = 56DD 1511 DDDA 56D7 99C7  B288 5CE5 A713 0969 A4D1