How dashed inconsiderate of johnney foriegner to want name files using esoteric, descriptive terms like:

• 数.文
• デ.タファイル
• 자료.파일
• архив.данных
• αρχείο.στοιχείω

Why can't they make do with something simple like data.file

How dashed inconsiderate of johnney foriegner to want name files using esoteric, descriptive terms

That was exactly my point: the problem arises because software has to identify the files with the same filenames that the users have to use. The demands on what can be put in a filename are not going to stop with relatively sane things like a larger character set. The filename, because it is used directly by users as an expression of the file's contents, will eventually be expected to be able to include, among other things, symbols that are not included in Unicode, including custom symbols that the user just made up and drew. Users will want files to be represented also with animations. And on it goes. All of that would be relatively reasonable, if it were just the user interface. On the Mac, ordinary data files can have their own icons attached to them, but that is pretty limited, because you've only got so many pixels to play with. On MS Windows and most Unices, you don't even have that.

The problem with putting arbitrary things in the filename is *not* a problem of allowing the user to describe the file with arbitrary information. The problem is that the filename is not just the user-side file description medium: it's also the program's interface. That means every time any ability gets added to the interface, every single application -- even behind-the-scenes apps like the ones in server space -- has to be reworked to support it. Unicode characters are only the beginning.

Much of this pain could be avoided if the representation shown in the file manager and the file selection dialog boxes were separate from the file identifier used by programs to identify the file. Presumably many command-line users would probably choose to specify files by their identifiers rather than by their representation, because the identifier would probably usually be easier to type, but there's no reason they couldn't be given the option to specify them by the representation if they so choose, if it's something they can find a way to type somehow. But why should GUI users be limited to only using file representations that can be typed? That would be an aweful lot like insisting that the Chinese stick to filenames that only contain ASCII characters. Either way, you're imposing a limitation on users because of an implementation detail that is unimportant to the users -- and when the users decide they're not willing to put up with it anymore, then you make chaos for all the programmers as they have to fix all the software to stop making assumptions about how file identifiers are structured.

Allowing more things to be put in filenames isn't going to solve the problem. Allowing spaces to be put in filenames didn't solve the problem; allowing Unicode characters is just more of the same band-aid. The only real solution is to separate the concept of a file identifier, which programs use to identify the file, from the concept of a representation that the user specifies and uses to keep track of what the file is about. Having the two be the same stopped making sense when people who weren't programmers started using computers.

---

Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy.

I 100% agree with you. I didn't get the above from your original post, but I see that was due to what I read, not what you wrote.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.