Re: Translations of folder names - two proposals

[Ryan McDougall <NQG24419 nifty com>]

On Sat, 2004-11-12 at 14:48 -0500, Havoc Pennington wrote:
> On Sun, 2004-12-12 at 03:35 +0900, Jan Morén wrote:
> > Hmm. So I would have a file selector that is lying to me? I would do "ls
> > ~", and see "Desktop", then use gedit to open a file and "Desktop" would
> > be nowhere to be found (replaced by "Skrivbord" or "机", depending on
> > what language I use that day)?
> 
> Now you're talking about the shell or Motif apps, and that brings me
> back to the original point: given a tradeoff between a downside for
> shell users and a downside for all users, the shell users should not be
> optimized for if we have our priorities right.
> 
> Note *given a tradeoff*. If someone steps up with the Perfect Solves
> Everything solution then there's no debate.
> 
> But our general principle to date has *not* been consistency with shell.
> Again:
> 
>  - file hierarchy is displayed as multi-rooted in file chooser
>  - the Computer folder in nautilus
>  - making mounted devices appear on the desktop, not in "ls ~/Desktop"
>  - any URI not starting with file:/// displayed in nautilus/filechooser,
>    these are not available in the shell or legacy apps
>  - .desktop files
>  - .directory files

I would say that the difference with the above and ~/Desktop is that we
think of the above as spatial objects -- we don't use "external
language" such as Names ("Desktop", "Templates", ...) that might need to
be translated. Once we start naming things in the UI, those names need
to be translated.

However, as Danilo correctly points out, once one tries to think of
~/Desktop as an inherently spatial Place instead of a Name, then the
confusion of "lying" to the user subsides a little ("A Rose by any other
name ..."). The problem comes from the belief that the user "owns" their
$HOME, and that everything (visible) in it is not a special place with
external (magic) rules (like self translation), but one that does only
what they tell it to (manual translation).

> 
> The point being, if you start saying "we have to be consistent with
> shell" we're going to have to go back and change all that stuff.
> And this shows that restricting ourselves to the UNIX filesystem model
> that shells use will have major negative UI consequences.

I don't think so. Its not quite right to simply call Unix "an
implementation detail" since GNOME is in fact intrinsically tied to
Unix. Its one thing to hide the messy details of the OS underneath, its
quite another to be in open disagreement with it. What you mention above
is a sole creation of the "GNOME world", and can live there without too
much trouble totally separated from whats beneath as long as its not in
active disagreement with Unix. 

The Unix file system isn't a design implementation that shouldn't be
exposed, its an inherent and deeply ingrained design choice that cannot
entirely be eliminated from the UI without a massive amount of pain.
Even MacOS exposes some of the nature of the file system. 

People have already mentioned some the problems that crop up in practise
when you try to abstract away something as fundamental as the whole OS
your running, so I won't repeat them here. 

Also, part of the success of GNOME and Linux is the Unix heritage,
including the command line. People use and need the shell, and simply
saying we can't afford to give anyone who uses the shell a sane UI
experience, is likely to alienate everyone who uses it and doesn't speak
English. Its one thing to learn "/sbin/fsck.ext3", which is *hardly*
English, and another to force them to also learn Desktop, Templates,
Public, and WhatEverWeNeedToAddNext.

And if bash needs to be fixed to accommodate *us*, then how do you
suggest it is supposed to know which directories are Magic (and thus
need to be auto-translated), and which aren't?

> 
> Havoc
> 

What Alan and I (since I prefer environment variables too) are asking
for is not to expose nasty Unixisms, but to argue that the simplest
method (KISS) is to keep the $HOME file system as pristine as possible,
and use that as the native store (instead of magic inside GTK).

The problem with dangling links is very real, but I believe its simpler
to provide a "Use this folder as my Desktop..." GUI, than to try to
constantly maintain an illusion that is in direct conflict with an
inescapable "implementation detail" (Unix).

Cheers,
Ryan