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

[eric jackson <shinobi@monkey.org>]

On Thu, 2 Nov 2000, Fyodor wrote:

> 
> 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] :)
> 


Port of FreeBSD work. It's in japanese, but the link to the code is
clear.. 

http://www.jp.netbsd.org/ja/JP/Documentation/japanese/netbsd-jp01-3.html

			eric


> ---/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
> 
>