Ada_Ru форум

������������!

� ����� ������������� ���������� ������ ��������� ����� ������������ 
������ ����������� ��������� Appendix A �������������� �������, 
���������� ����������� �������� ���������, ����������� ��� ������������� 
�������� � �.�.

��� ������ ��������� ������ �������� ������������ ������ 
Ada.Characters.Wide_Cyrillic, ������������� ���� ���� ���������. � 
������ ��� ����� ����� Ada.Characters.Wide_Latin_1, �� � ��������� 
������� �� ���� ��� �������, �� ����������� � ������������� ������ � 
�������������� � "��������������" ������� ����������� �������� 
(��������, ����� ��� ���� ���������, ���� ������ � �.�.). ��� �������� 
�� ������� "����������" ���� �������� ��� ������������� ������������� � 
��������� ������� Wide_Latin_1 � Wide_Cyrillic.

����� ����� ��������-�� ����� ����������� ����� ��� ������������� ����� 
��������, �������������� ���������/�������� ����. ������������ � 
AI-00285 ������� ���� �������� �� ������ �������� � ����� ��������. 
���������� ����� Ada.Characters.Cyrillic.Handling ���������� ��-�� 
������������� ����������� ������ Ada.Characters.Cyrillic. ���������� 
��������� ������ ����� ��� �������:
- ��� Character �� ������������ ����������� ������������� ���� ������� 
��������, ����� Latin_1, ��� ������������ ������� ����������� 
������������ ��������������� ������� Ada.Characters.Handling � 
Ada.Strings.Maps.Constants;
- ���������� ������� ��������� ������������� ������������� ���� � 8-�� 
������ �������� (��� �������� �� ������� ���� ��������� ���������: 
����/ECMA/ISO-8859-5, ���-8 (U, R), ���� ����, CP866, CP1251, Mac). 
��������-�� ����� ������� Cyrillic_ISO, Cyrillic_KOI � �.�. � ����� 
������� ������ �����, � � ������ ������� ��� ������ ������� 
������������� ��������.

����� �������

[ Attachment content not displayed ]
[ Attachment content not displayed ]

Hi !

Am Samstag, 7. Dezember 2002 13:53 schrieb Vadim Godunko:

> - отсутствие единого стандарта представления кириллических букв в 8-ми
> битных символах (мне известны по крайней мере следующие кодировки:
> ГОСТ/ECMA/ISO-8859-5, КОИ-8 (U, R), ГОСТ ДКОИ, CP866, CP1251, Mac).
> Городить-же набор пакетов Cyrillic ISO, Cyrillic KOI и т.д. с одной
> стороны просто глупо, а с другой стороны это только ухудшит
> переносимость программ.

UTF-8/UNICODE, остальное в мусорку.

К стыду своему, ничего в этом не понимаю. :((

Могу сказать только:

1. Выглядит солидно
2. Вещь крайне нужная

Ilja Wasiltschenko wrote:
> 
>>- отсутствие единого стандарта представления кириллических букв в 8-ми
>>битных символах (мне известны по крайней мере следующие кодировки:
>>ГОСТ/ECMA/ISO-8859-5, КОИ-8 (U, R), ГОСТ ДКОИ, CP866, CP1251, Mac).
>>Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной
>>стороны просто глупо, а с другой стороны это только ухудшит
>>переносимость программ.
> 
> UTF-8/UNICODE, остальное в мусорку.
> 
На мой взгляд, не стоит забывать и о UCS-2, UCS-4.

hi,

Vadim Godunko wrote:

> Здравствуйте!
>
> В свете происходящего пересмотра нового стандарта языка предлагается
> внести предложение дополнить Appendix A спецификациями пакетов,
> содержащих определения символов кириллицы, константами для классификации
> символов и т.д.

мысль оч даже хорошая!!!
только вот задачка эта не так проста как может показаться
на первый взгляд :(


> Предлагаемое в
> AI-00285 решение этой проблемы не совсем подходит в наших условиях.

почитал я это AI-00285...
тут, imho, "собака глубжее зарыта"...
опять же imho, к сожалению они рассматривают только часть проблемы:
только то что касается символов и кодировок, а это только половина дела
(правда, справедливо заметить, что довольно значительная).
более корректно это было бы обозвать проблемой поддержки локализации.

> Определить пакет Ada.Characters.Cyrillic.Handling невозможно из-за
> необходимости определения пакета Ada.Characters.Cyrillic. Определить
> последний мешает целый ряд проблем:

эт точно :(

> - тип Character не представляет возможности использования иных наборов
> символов, кроме Latin_1, без мистического способа подстановки
> компилятором соответствующих пакетов Ada.Characters.Handling и
> Ada.Strings.Maps.Constants;
> - отсутствие единого стандарта представления кириллических букв в 8-ми
> битных символах (мне известны по крайней мере следующие кодировки:
> ГОСТ/ECMA/ISO-8859-5, КОИ-8 (U, R), ГОСТ ДКОИ, CP866, CP1251, Mac).

есть, кажись, еще koi8-e/koi8-f...
"больше стандартов хороших и _разных_"

> Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной
> стороны просто глупо, а с другой стороны это только ухудшит
> переносимость программ.

сложно сказать. дело в том, что 8-битные кодировки тоже нужны,
хотябы для взаимодействия с так называемыми "малыми системами"

>
>
> Вадим Годунко

Alex

> > Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной
> > стороны просто глупо, а с другой стороны это только ухудшит
> > переносимость программ.
>
> сложно сказать. дело в том, что 8-битные кодировки тоже нужны,
> хотябы для взаимодействия с так называемыми "малыми системами"

Не уверен что нужно обязательно вводить все кирилические кодировки в
стандарт.
Если в россии в кодировками бардак, это не значит что стандарт Ада должен
тоже отражать этот бардак.
А кодировки других языков в стандарт вводят, кто нибудь в курсе ?
И в каком виде это дело происходит с другими языками, где нибудь есть эта
информация ?

Oleksandr Havva wrote:
> 
>>Предлагаемое в
>>AI-00285 решение этой проблемы не совсем подходит в наших условиях.
> 
> 
> почитал я это AI-00285...
> тут, imho, "собака глубжее зарыта"...
> опять же imho, к сожалению они рассматривают только часть проблемы:
> только то что касается символов и кодировок, а это только половина дела
> (правда, справедливо заметить, что довольно значительная).
> более корректно это было бы обозвать проблемой поддержки локализации.
> 
Похоже именно то, что называется "локализацией" они и хотят обойти. По 
большому счету я с ними согласен (пример. Записав текстовый файл с 
цифрами с плавающей точкой в локализации ru, я его не прочту в 
локализации en. Почему? Думаю все и сами догадались: у нас дробную часть 
отделяет запятая, а у них - точка. И это только цветочки.)

Естественно поставить вопрос что делать с локализациями. Наилучшим 
решением видится создание отдельных модулей, не обязательных для 
поддержки всеми производителями. Но в этой сфере моих знаний явно не 
достаточно, что бы что-то предлагать. Хотя и очень хочется иметь таковое.

> 
>>Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной
>>стороны просто глупо, а с другой стороны это только ухудшит
>>переносимость программ.
> 
> сложно сказать. дело в том, что 8-битные кодировки тоже нужны,
> хотябы для взаимодействия с так называемыми "малыми системами"
> 
именно наши "малые" системы и принесли этот хаос. И переносить хаос в 
стандарт не хотелось-бы. А вот разработать модули для поддержки этого 
бардака можно (а может и нужно). Если кому нужна будет связь со старыми 
системами - нет проблем, пожалуйста. А новые извольте строить по 
человечески.

В настоящее время у меня есть модули для работы в ГОСТ/ECMA/ISO-8859-5. 
Работает преобразование Character <=> Wide_Character, классификация 
буква, цифра. Но дело встало при попытке определить "базовые" символы. С 
русскими проблем нет. В "небазовые" входит только Ё и ее базовый аналог 
Е. А вот что делать с украинскими/белорусскими буквами - понятия не 
имею. Если кто знает - прошу помочь. Можно будет доделать и выложить на 
сайт.

Вадим

Dmitriy Anisimkov wrote:
> 
> А кодировки других языков в стандарт вводят, кто нибудь в курсе ?
> И в каком виде это дело происходит с другими языками, где нибудь есть эта
> информация ?
> 
Все, что мне известно, это обозначенный AI. Там предлагается поддержка 
ISO-8859-15 (Latin9). Суть проста - Европа, объединившись, решила 
сделать единую валюту. Это-то ничего, да они придумали для обозначения 
её специяльный значок. Вот они и продвигают эту кодировку.

А я подумал, что под эту волну можно и кириллизацию протолкнуть...

hi,

Dmitriy Anisimkov wrote:

> > > Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной
> > > стороны просто глупо, а с другой стороны это только ухудшит
> > > переносимость программ.
> >
> > сложно сказать. дело в том, что 8-битные кодировки тоже нужны,
> > хотябы для взаимодействия с так называемыми "малыми системами"
>
> Не уверен что нужно обязательно вводить все кирилические кодировки в
> стандарт.
> Если в россии в кодировками бардак,

ежели б бардак был только с кирилличными кодировками,
то это было бы не так грустно
насколько мне известно, то 8-битных кодировок, для поддержки различных
нац. особенностей и языков существует более сотни
(это только то что мне известно!!!)

> это не значит что стандарт Ада должен
> тоже отражать этот бардак.
> А кодировки других языков в стандарт вводят, кто нибудь в курсе ?
> И в каком виде это дело происходит с другими языками, где нибудь есть эта
> информация ?

более-менее полно проблемы локализации решаются
_только_ библиотеками поддержки языков линии С/С++
возможно именно поэтому они такие вездесущие :(
локализация в целом описывается стандартами ISO

Alex

hi,

Vadim Godunko wrote:

> Похоже именно то, что называется "локализацией" они и хотят обойти.

imho, "половинность" решения не есть хорошее решение

> По
> большому счету я с ними согласен (пример. Записав текстовый файл с
> цифрами с плавающей точкой в локализации ru, я его не прочту в
> локализации en. Почему? Думаю все и сами догадались: у нас дробную часть
> отделяет запятая, а у них - точка. И это только цветочки.)

эт точно :(

> Естественно поставить вопрос что делать с локализациями. Наилучшим
> решением видится создание отдельных модулей, не обязательных для
> поддержки всеми производителями. Но в этой сфере моих знаний явно не
> достаточно, что бы что-то предлагать. Хотя и очень хочется иметь таковое.

похоже, опять же imho, что достаточно компромиссным решением
является реализация поддержки локали в glibc
там все данные локализации располагаются отдельно от
самих алгоритмов, за счет чего все алгоритмы (подпрограммы)
унифицированы и едины. сменной частью являются сами данные
локализации, что кстати, позволяет добавлять/убирать различные
данные локализации не затрагивая самих бинарников библиотеки.

> >
> >>Городить-же набор пакетов Cyrillic_ISO, Cyrillic_KOI и т.д. с одной
> >>стороны просто глупо, а с другой стороны это только ухудшит
> >>переносимость программ.
> >
> > сложно сказать. дело в том, что 8-битные кодировки тоже нужны,
> > хотябы для взаимодействия с так называемыми "малыми системами"
> >
> именно наши "малые" системы и принесли этот хаос. И переносить хаос в
> стандарт не хотелось-бы. А вот разработать модули для поддержки этого
> бардака можно (а может и нужно). Если кому нужна будет связь со старыми
> системами - нет проблем, пожалуйста. А новые извольте строить по
> человечески.

не во всех новых системах будет присутствовать возможность
"воткнуть" полновесный юникод, и именно по причине "малости"
системы. примеров могу насыпать... прям со старта :)

> В настоящее время у меня есть модули для работы в ГОСТ/ECMA/ISO-8859-5.
> Работает преобразование Character <=> Wide_Character, классификация
> буква, цифра. Но дело встало при попытке определить "базовые" символы. С
> русскими проблем нет. В "небазовые" входит только Ё и ее базовый аналог
> Е. А вот что делать с украинскими/белорусскими буквами - понятия не
> имею.

ага...
сюрпрайз: кириллицу не только в Беларуси/России/Украине пользують
есть еще болгары и югославы... может и еще кто, не помню

> Если кто знает - прошу помочь. Можно будет доделать и выложить на
> сайт.

пытался я с этими делами разбираться, да переключился
на писательство буки. разрываться на части - не хоц-ца,
да и производительность моя не безпредельна :(
...опять же, основную работу тоже надо работать.

в обчем так-с...
делал я себе на эту тему базу данных по символам и кодировкам
на Interbase. оно не так чтоб супер база, а скорее инструмент,
для проверки кодов, плюс была идея генерить sql-скриптами
файлы исходников с таблицами кодов символов
(кстати, можно было бы не только под Аду!).
данные я брал из исходников glibc с оглядкой на UNICODE
версии 2-с-чем-то.
ежели такая поделка сгодиться то могу этим "чудом"
поделиться, только мне на вспоминания/разборки
день два точно понадобиться


>
>
> Вадим

Alex

Oleksandr Havva wrote:
> 
>>Похоже именно то, что называется "локализацией" они и хотят обойти.
> 
> imho, "половинность" решения не есть хорошее решение
> 
Полная локализация интересна и применима только для полновесных 
интернациональных программных продуктов. Большая же часть ПО писанного 
на Ada к таковым не относятся. И "половинность" решения здесь считай 
"полное" решение.

> 
> похоже, опять же imho, что достаточно компромиссным решением
> является реализация поддержки локали в glibc
> там все данные локализации располагаются отдельно от
> самих алгоритмов, за счет чего все алгоритмы (подпрограммы)
> унифицированы и едины. сменной частью являются сами данные
> локализации, что кстати, позволяет добавлять/убирать различные
> данные локализации не затрагивая самих бинарников библиотеки.
> 
А вот и не угадали. Последние версии (glibc-2.2) библиотеки используют 
массу "подгружаемых" модулей для реализации различных функций. В Ada это 
невозможно (если, конечно не извращаться).

> 
> не во всех новых системах будет присутствовать возможность
> "воткнуть" полновесный юникод, и именно по причине "малости"
> системы. примеров могу насыпать... прям со старта :)
> 
"Огласите, пожалуйста, весь список."

Малость на мой взгляд - микроконтроллеры. Но и программировать их на Ada 
- глупость. А вот все остальное оборудование уже на сегодняшний день 
обладает достаточными резервами памяти всех пород. И, кстати, никто не 
требовал использовать UNICODE. Речь идет исключительно о действующем 
стандарте ISO. А он на данный момент остановился на 16-ти битном 
представлении символов. Я согласен, что UNICODE пошел дальше, но в 
последней своей инкарнации он "тяжел" и для рабочих станций.

> в обчем так-с...
> делал я себе на эту тему базу данных по символам и кодировкам
> на Interbase. оно не так чтоб супер база, а скорее инструмент,
> для проверки кодов, плюс была идея генерить sql-скриптами
> файлы исходников с таблицами кодов символов
> (кстати, можно было бы не только под Аду!).
> данные я брал из исходников glibc с оглядкой на UNICODE
> версии 2-с-чем-то.
> ежели такая поделка сгодиться то могу этим "чудом"
> поделиться, только мне на вспоминания/разборки
> день два точно понадобиться
Наверное пока не стоит делиться "чудом". Проше скачать с www.unicode.org 
все необходимые (и не очень необходимые) таблицы.

Вадим

hi,

Vadim Godunko wrote:

> Полная локализация интересна и применима только для полновесных
> интернациональных программных продуктов. Большая же часть ПО писанного
> на Ada к таковым не относятся. И "половинность" решения здесь считай
> "полное" решение.

так-то оно так, но может "оно" как раз и не относится
к "полновесным интернациональным программным продуктам"
ввиду того что полновесной поддержки нет?
с этим делом что-то типа замкнутого круга получается,
или мне это только кажется?

> >
> > похоже, опять же imho, что достаточно компромиссным решением
> > является реализация поддержки локали в glibc
> > там все данные локализации располагаются отдельно от
> > самих алгоритмов, за счет чего все алгоритмы (подпрограммы)
> > унифицированы и едины. сменной частью являются сами данные
> > локализации, что кстати, позволяет добавлять/убирать различные
> > данные локализации не затрагивая самих бинарников библиотеки.
> >
> А вот и не угадали.

ну... угадывать, предположим, я не угадывал...
просто, (согласен, каюсь) я несколько идеализировал реализацию
самой идеи - отделение данных локализации от подпрограмм
которые от нее (локализации) зависят.

> > не во всех новых системах будет присутствовать возможность
> > "воткнуть" полновесный юникод, и именно по причине "малости"
> > системы. примеров могу насыпать... прям со старта :)
> >
> "Огласите, пожалуйста, весь список."
>
> Малость на мой взгляд - микроконтроллеры. Но и программировать их на Ada
> - глупость. А вот все остальное оборудование уже на сегодняшний день
> обладает достаточными резервами памяти всех пород.

в качестве примера:
ISDN-телефоны (уж звиняйте, но вот с техникой связи мне как раз
в настоящее время и приходится возиться)
одна из возможностей этой игрушки - отображение на ЖК индикаторе
(для справедливости замечу, что ИЖК не все модели имеют)
кроме номера того _кто_ Вам звонит, или с кем Вы в текущий
момент разговариваете, еще и отображение имени/фамилии звонящего.
кроме того, на этом же ИЖК отображается дата/время.
не трудно догадаться, что желательно чтобы все это
было в соответствии с национальными особенностями.
засунуть в это устройство весь юникод (даже только BMP)
не получиться. и это проблема даже не в наличии памяти,
дело в том, что телефон питается от станционного абонентского
комплекта. следовательно, дополнительные устройства внутри
телефона дополнительно "нагружают" абонентский комплект по питанию.
посему подгрузить по D-каналу 8-битную кодировку в такое устройство
и далее работать с ним используя 8-битную кодировку будет дешевле.

надеюсь суть идеи понятна.
подобных устройств не так мало, как может показаться сначала.
к тому же это как раз тот класс систем, который называют
встроенными системами реального времени, то есть область
применения Ады.

> И, кстати, никто не
> требовал использовать UNICODE. Речь идет исключительно о действующем
> стандарте ISO. А он на данный момент остановился на 16-ти битном
> представлении символов. Я согласен, что UNICODE пошел дальше, но в
> последней своей инкарнации он "тяжел" и для рабочих станций.

на предмет того, что 16-битных Wide_Character хватит на 99,9999%
приложений - тут я полностью согласен.
но вот полновесной поддержки даже этого BMP в Аде сейчас нет -
поддерживается ведь только подмножество Latin-1


Alex

Oleksandr Havva wrote:
> 
>>Полная локализация интересна и применима только для полновесных
>>интернациональных программных продуктов. Большая же часть ПО писанного
>>на Ada к таковым не относятся. И "половинность" решения здесь считай
>>"полное" решение.
> 
> 
> так-то оно так, но может "оно" как раз и не относится
> к "полновесным интернациональным программным продуктам"
> ввиду того что полновесной поддержки нет?
> с этим делом что-то типа замкнутого круга получается,
> или мне это только кажется?
> 
И да и нет. Поясню. Предположим, хочется нам написать систему управления 
и контроля Тихоокеанским флотом. Нужна нам интернационализация? 
Вообще-то нет. Теперь предположим, хочется написать текстовый процессор. 
Нужна нам интернационализация? Уж точно не помешает.

Как видно - все зависит от круга конечных пользователей. Из-за 
ориентации в первую очередь на приложения первой группы, Ada не 
требуется поддержки интернационализации. Но это снижает её 
привлекательность для информационных систем, где некоторые части 
интернационализации _обязаны_ присутствовать (например, сравнение строк 
для сортировки, особенности представления десятичных чисел, валют).

> 
> в качестве примера:
> ISDN-телефоны (уж звиняйте, но вот с техникой связи мне как раз
> в настоящее время и приходится возиться)
> одна из возможностей этой игрушки - отображение на ЖК индикаторе
> (для справедливости замечу, что ИЖК не все модели имеют)
> кроме номера того _кто_ Вам звонит, или с кем Вы в текущий
> момент разговариваете, еще и отображение имени/фамилии звонящего.
> кроме того, на этом же ИЖК отображается дата/время.
> не трудно догадаться, что желательно чтобы все это
> было в соответствии с национальными особенностями.
> засунуть в это устройство весь юникод (даже только BMP)
> не получиться. и это проблема даже не в наличии памяти,
> дело в том, что телефон питается от станционного абонентского
> комплекта. следовательно, дополнительные устройства внутри
> телефона дополнительно "нагружают" абонентский комплект по питанию.
> посему подгрузить по D-каналу 8-битную кодировку в такое устройство
> и далее работать с ним используя 8-битную кодировку будет дешевле.
> 
Согласен. Но просчитать сегодняшние затраты с учетом завтрашнего 
развития техники и, возможно, пойти по 16-ти битному пути, не помешает. 
Ведь перешли сотовые телефоны на UCS-2. И даже виртуальную машину Java в 
них впихнули. И вполне может оказать выгодным сегодня принимать и 
отображать в ISO/KOI/... а вот внутренние алгоритмы строить на UNICODE. 
А завтра выкинуть конвертор на входе/выходе и получить "современное" 
решение. И сбить за UNICODE-зацию очередную порцию финансов.

> 
> на предмет того, что 16-битных Wide_Character хватит на 99,9999%
> приложений - тут я полностью согласен.
Я бы убрал одну девятку ;-)

> но вот полновесной поддержки даже этого BMP в Аде сейчас нет -
> поддерживается ведь только подмножество Latin-1
> 
Тоже согласен. Но бороться надо. Если кто будет об этом кричать - все 
задумаются. А будут молчать - скажут, что это никому не требуется. А в 
обозначенном AI именно к этому все и свелось.

Вадим

hi,

Vadim Godunko wrote:

> > с этим делом что-то типа замкнутого круга получается,
> > или мне это только кажется?
> >
> И да и нет. Поясню. Предположим, хочется нам написать систему управления
> и контроля Тихоокеанским флотом. Нужна нам интернационализация?

...если для 6-го флота США, US Air Force... - точно не надо :)
достаточно ASCII, который уже со времен Ады-83 живет.

...а вот для Тихоокеанского, а потом еще Балтийского...
иметь _стандартные_ механизмы поддержки кириллицы
оч даже надо. иначе, при реализации:
для Тихоокеанского _будут_ написаны _тихоокеанские_
средства поддержки кириллицы (и прочих национальных
особенностей), а для Балтийского - _балтийские_.
ввод/вывод информации ведь на русском придется обеспечивать,
или любой матрос Тихоокеанского флота уже запросто на
английском speak-ает? ;)

> Согласен. Но просчитать сегодняшние затраты с учетом завтрашнего
> развития техники и, возможно, пойти по 16-ти битному пути, не помешает.
> Ведь перешли сотовые телефоны на UCS-2.

мерзость в том, что сотовый телефон для такого примера
не совсем годиться, потому как батарейка у сотового - своя,
и ежели она каждые два часа у пользователя будет садиться,
то центральной системе это до лампочки.

подобными свойствами ISDN телефонов обладают устройства
консолей охранных систем, консоли управления/диагностики
на автоматизированных производственных линиях и тд и тп

> И даже виртуальную машину Java в
> них впихнули. И вполне может оказать выгодным сегодня принимать и
> отображать в ISO/KOI/... а вот внутренние алгоритмы строить на UNICODE.

imho, на N лет вперед достаточно построить внутренние алгоритмы
вокруг BMP (ISO-10646), с соответственной поддержкой
ввода/вывода. этого ведь в нынешнем стандарте Ады
(и не только Ады) нету :(
думаю, понятно _что_ я подразумеваю

> А завтра выкинуть конвертор на входе/выходе и получить "современное"
> решение. И сбить за UNICODE-зацию очередную порцию финансов.

а с кого финансы будем "очередными порциями" сбивать?
я тожа хачу :)
...а, ежели серьезно, то на счет сбития "очередных порций финансов"
я не так оптимистичен

> >
> > на предмет того, что 16-битных Wide_Character хватит на 99,9999%
> > приложений - тут я полностью согласен.
> Я бы убрал одну девятку ;-)

э-э-э... надо же чего-нить оставить и "на всякий случай" :)))

> > но вот полновесной поддержки даже этого BMP в Аде сейчас нет -
> > поддерживается ведь только подмножество Latin-1
> >
> Тоже согласен. Но бороться надо. Если кто будет об этом кричать - все
> задумаются. А будут молчать - скажут, что это никому не требуется. А в
> обозначенном AI именно к этому все и свелось.

ага, вывешиваем баАальшущий лозунг:
"Все на _борьбу_ с локализацией/кириллизацией!!!" :)))
шутю, ес-сно

если серьезно, то - таки _да_, надо искать пути решения
этих проблем, потому как нас это гораздо сильнее касается
чем США/Европу - кириллица у нас

вообще, похоже что мы оба достаточно хорошо себе представляем
как необходимость решения этой проблемы, так и то, насколько
эта проблема не проста.

Alex