[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: recent-file-spec: possible design flow ?

I think we must differenciate here:

the first problem is that we can't present the file's name to the user appropriatly if it has been created using a different encoding. This problem could only be solved by adding multi-encoding support to the file systems or to the file system layer (writing file names always in utf-8), which is not very likely to happen. The same could be achieved by installing only utf-8 locales on a system. Unfortunatly utf-8 locales seem not be very popular in the CJK-countries.

The second problem is that even though it may not be possible for the user to type the file name in his (different) locale, there is no reason why he should not be able to _open_ it through either a (double-)click in his file manager or a auto completion functionality in a file picker dialog.

Unfortunatly the sequence:

locale encoding file name -> unicode file name -> unicode file url

instead of:

locale encoding file name -> file url (ascii) -> unicode file url

prevents the user from being able to do so :(.

- Oliver

Brenden T. wrote:

Oliver's use case explains the issue pretty well. To me this sounds like a file system problem, not something the gui should try to solve. I don't see how any application can work if the encoding of file and path names is not precisely specified for a mounted disk.

Heck, what happens on multi-user system? One guy starts up in C, another wants to use his native, non-english language, and they are both writing *differently encoded filename* strings to the same partition? *shudder*

Does the Linux Standard Base define any type of filename string encoding? I'm too lazy to look it up...

Seems to me like you should ask the file system people to put the encoding in the superblock. Then everybody uses the same encoding for a given mounted drive, and the app (or better, some system library) translates between what the file system encodes and what the user has requested be displayed. Then an admistrator could chose the encoding during installation, or a distro can choose a default (C for Red Hat boxes sold in the US, zh.BIG5 for a Chinese distro, etc., etc.).

This may not work as well for floppy drives and CDROMs, but hey you have to start somewhere.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]