Что такое локализация и какой она должна быть в системе
На основе некоторых писем, требует добавления
Полноценная локализация подразумевает полную и всестороннюю поддержку бытующих в наших странах языков, стандартов и предпочтений пользователей, и перевод интерфейса – это только первое приближение к ней. Русский и все прочие языки должны поддерживаться в той же мере, что и английский при любом взаимодействии системы с пользователем.
Думать что настоящая локализация вообще возможна в существующих реалиях Linux – большая ошибка.
Причины этого:
Отсутствие механизмов интернационализации для объектов типа ядра, системных служб (например syslog), файловых систем, ряда системных утилит и пр. Конечно, речь идёт только о сфере человеко-машинного взаимодействия, а не внутреннем обмене информацией между программами.
Отсутствие средств автоматизации процесса перевода документации. Необходима доработка уже имеющихся систем TM для прямой поддержки используемых форматов документации (прежде всего Docbook, man, info) + общая организация. Пора выходить из каменного века ручной работы.
gettext решает только часть проблем интернационализации. Всё остальное еще надо сделать общими усилиями.
Я в своё время был полон энтузиазма и надеялся, что будучи российско-украинско-белорусско ориентированным дистрибутивом, ALTLinux будет двигаться к лучшей поддержке i18n и i10n с учётом реалий СНГ, но это оказались иллюзии. Локализацию собственно системы ALT просто не поддерживает. Более того, часто делаются возмутительные заявления и призывы отказаться от поддержки i18n на более глубоком уровне, чем меню программ по смехотворным поводам, вроде «слетания шрифта» в консоли или нескрываемого наплевательства разработчиков.
/ВячеславДиконов
Вот некоторые раздражающие следствия существующих проблем;
сложности с использованием русских имён файлов и их переносом на другие машины (Windows здесь в лучшем положении). Это практически решено с появлением libnatspec, хотя её внедрение продвигается не так быстро, как хотелось бы.
невозможность перевода сообщений ядра
Хранить базу переводов в ядре нерационально, но при нынешних объёмах памяти вполне реально.
Так можно и не хранить. Если никак нельзя динамически подключать i10n ресурсы или помещать их в initrd, то уж при сборке ядра выбрать другой язык можно, и для этого кое-что уже сделано. Существуют перевод сообщений ядра на русский и кириллический шрифт для загрузки вместе с ядром. /VitalyLipatov
Желаемые язык/шрифт можно было бы указывать при установке системы как локаль данной машины по умолчанию. Если какие-то программы неспособны работать в отличающемся от локали автора окружении, то их нужно срочно исправлять. /DenisSmirnov// syslog — хм. Сложно это. Но нужно. Только не на уровне syslog, а именно на уровне софта для его просмотра. /AndreyOrlov//Я обосную. Из опыта личной работы с пользователями виндоус. Чтобы пользователь виндоуз мог прочитать сообщение вслух службе саппорта по телефону. Прочитать сообщение по-английски они не могут. В принципе, подход под названнием «напечатать код ошибки, который можно посмотреть в справочнике», эту проблему тоже решает и может быть даже лучше: проговаривание голосом цифр – наиболее надежный метод передачи голосом.
невозможность русских паролей и имён пользователей (cм. Windows)
/VitalyLipatovпри вводе пароля вообще не должна учитываться раскладка, это и решает проблему. А системное имя пользователя является частью его адреса e-mail и соответственно локализовано вряд ли может быть. Тут мне кажется в стране, где все поголовно учили в школах иностранный язык, латинские буквы люди должны знать. Поле GECOS (где обычно пишут полное имя пользователя), должно бы быть записано в кодировке системной локали).
отсутствие поддержки перевода сообщений системных служб при загрузке (см. старый Red Hat)
уже рассмотренные проблемы локализации журналов.
Сложность их исправления – следствие «плохих» технических решений, которые мы используем.