[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [locale] Re: [locale] "Кpивой" strcoll() в glibc 2.2
On Thu, 12 Jul 2001, Alexander Mikhailian wrote:
> Многие лингвисты отрицательно относятся к идее локали как
> таковой, считая её необоснованным обобщением, особенно в
> связи с повальной модой на "корректную", локализацию
> программных продуктов с использованием средств,
> предоставляемых операционной системой, будь то Microsoft
> Windows, Linux или Solaris. Впрочем, для ITшников всё тоже
> неочевидно.
>
> Вот три случая из личной практики многоязыковой поддержки:
>
> 1. Интернациональная компания, сотни людей работают с
> десятками языков. Вдруг выясняется, что программа-клиент для
> удалённого редактирования баз данных не запускается на
> некоторых компъютерах. Беглый взгляд на проблему показывает,
> что программа-клиент не работает на системах с локалями, в
> которых даты представляются в другом формате, чем тот,
> который требует сервер баз данных. Всё заканчивается
> методичным обходом рабочих мест и изменением локали на US.
>
> 2. Та же интернациональная компания, те же сотни людей,
> говорящих на десятках языках. При беглом взгляде на стенку
> рядом с рабочим столом одного из менеджеров, обнаруживаю
> список дней недели на дюжине языков, включая корейский и
> японский. Удивляюсь и делаю комплимент насчёт
> любознательности, на что менеждер отвечает, что ему не до
> ин.языков, но что иногда приходят документы, в которых даты
> стоят в локали системы, на которой создавались документы.
> Вот и сделал себе шпаргалку.
>
> 3. Всё та же интернациональная компания, те же люди и
> многоязычие. Группа разработчиков изучает код на Visual
> Basic'e, который почему-то не работает на одной-единственной
> машине в группе. Через 15 минут мозговой атаки выясняется,
> что код считывает из файла числа в локалезависимой манере
> - соответственно, в системе, например, с русской локалью,
> число 10,101 будет означать не то же самое, что в системе
> с английской локалью.
Однако в 1,3 POSIX locale API позволяет полноценно и элегантно решить эти
проблемы путем временной смены локали на C локаль при обработке данных, формат
которых зависит от локали.
В 2) просто виноват софт для просмотра всех документов. По крайней мере в
офисном софте от MS эти даты вроде бы представлены как поля, то есть с
визуальным представлением поля есть и еще грубо говоря машинное представление.
А вот с strcoll()/strcasecoll() - это действительно проблема, так как
отсутствует даже API для обработки таких ситуаций.
Best regards,
-Vlad