[Comm] И снова о Unicode (Was: Каталог disk в /mnt)

[Вячеслав]

В Срд, 02/03/2005 в 20:36 +0300, Alexey Rusakov пишет:
> On 02.03.2005 19:12, Вячеслав Диконов wrote:
> > Кто такой zsh, и почему его глюки должны меня волновать?
> Это штука такая квадратная. Ей mike@ пользуется :)
> Если серьёзно - потому что они волнуют любого, пользующегося zsh, а это 
> довольно большой процент пользователей ALTLinux. Я не хочу иметь каталог 
> "Документы", названный в Unicode, не будучи в состоянии внятно написать 
> его название в zsh.
Официально ввести UTF-8 параллельно с сохранением всех существующих
локалей. Кому нужна zsh, могут utf-8 не включать. Можно сделать сборку
ncurses и прочего барахла специально для utf с правками от Федоры. Я
делал у себя подобное.

> > Наутилус уникод показывает всегда, независимо от локали.
> Я бы даже сказал - независимо ни от чего. Это не достоинство, как 
> показывает опыт обращения к не-Unicode ресурсам вне локальной машины.
Это общее свойство всего, что на GTK2.

> > VFS - не уверен, но думаю, что будет.
> VFS сейчас также независимо ни от чего использует для показа системную 
> локаль. Как, собственно, и все шеллы, что порядком нивелирует эффект от 
> перевода VFS на Unicode. Результат этой независимости столь же уродлив, 
> как и в случае Nautilus. Ещё хуже то, что сейчас в ALTLinux системная 
> локаль не уникодная, следовательно, угодив одной системе, обязательно 
> обижаешь другую. Вот в какой кодировке мне на FTP файлы класть, чтобы и 
> из командной строки с ними работать, и из Наутилуса?
А Наутилус, похоже учится. Я писал об этом в Гномову багзиллу и реакция была. 

> > Давно понятно, что представление имен файлов не должно зависеть от
> > локали. Единственное известное мне решение, позволяющее хранить
> > многоязычные строки независимо от локали - уникод. Линуксовые ФС в этом
> > случае отстают от жизни.
> Во-первых. ФС тут ни при чём, потому что ФС за _представление_ имён не 
> отвечает. Моему /home всё равно, какая у меня там локаль или что. Что 
> записали, то и отдаёт. Если уж нагружать перекодировкой между системной 
> локалью и Unicode'ом, то glibc, иначе в каждую файловую систему придётся 
> тянуть iconv.
glibc, так glibc. Тут я не претендую.

> Во-вторых и главных. Представление _должно_ зависеть от локали, на то 
> оно и представление. Берём /home/someone, расшариваем его в сеть. 
> Русскоязычные пользователи видят "Документы", казахи видят что?
То, что сами создали. Личные каталоги создает сам пользователь. Любое
другое решение - произвол.

> правильно, тоже "Документы". Мне не кажется, что это хорошо.
> Строго говоря, с содержимым "Документов" тогда тоже нужно что-то делать. 
> Но это уже забота пользователя, а каталог создаётся автоматически и мы 
> можем предоставить локализованное имя.
Не надо автоматически или только один раз. Никогда нельзя насильно
восстанавливать сознательно удаленное пользователем. 

> Заметьте, в GNOME имя desktop-файла не фигурирует, по-моему, нигде - 
> вместо этого для показа используется то, что внутри написано, с учётом 
> локали.
Верно.
> <dreaming>
> Идеалом, конечно, было бы, если бы файловая система могла хранить 
> локализованные имена, привязанные к данным inode... И отдавать их в 
> зависимости от региона, локали...
> </dreaming>
if ($name in @CODERS) { do_it } 
	elsif ($name in @translators) {translate};?
-- 
Вячеслав Диконов <linuxbox на degunino.net>