Re: Special folders in gnome

> > > If you don't use the same name on disk and in the UI, you get incorrect
> > > result as soon as people don't use apps which are able to get the name
> > > of applications : shell,
> > 
> > The shell is strange, and always will be, whatever we do.
> Problem is not really shell by itself (well, it can be for support /
> admin people) but shell scripts..

Yeah, you're going to have huge problems with shell scripts if you
multiple possible names for folders, which might change underneath them.
I wouldn't trust shell script authors to (know to) always go through a
> > >  KDE applications, whatever apps not GNOME
> > > related.
> > 
> > Of course we'd need to standardize this. We already share a standard
> > with KDE for $HOME/Desktop/, and I guess that KDE also translate the
> > name of Desktop in their UI.
> Well, we no longer translate Desktop anymore in the latest version of
> GTK File selector.

We don't? Why not?

> > But if an application's (non-GTK+, non-Qt) file chooser doesn't
> > translate it, the effect is only that a Chinese person sees an English
> > folder name. Not the end of the world.
> I don't agree with you. I think it is very problematic if we want to be
> credible on the desktop outside the english world. It is a matter of
> polish or fixing the rough edges. Without this, people will always say
> "look, it sucks, blabla". One of the reason of Apple success is IMHO
> their sense of the polish.

But translating the UI gives us a way to make this happen. Non GTK+ and
non-Qt apps are always going to be strange in all kinds of other ways

By the way, I think Apple translate in the UI (maybe in the Shell too),
but not on disk. I'm not sure how that looks when you ssh into an Apple
box. Maybe it's a filesytem thing.

> > But if we encourage translated on-disk folder names then we get multiple
> > instances of the same folder when applications hard code the names. This
> > is what we experience on Windows, even though the API to avoid this is
> > available to all applications.
> > 
> > It's a lot safer to hope that developers use some API to translate in
> > the UI than to hope that developers use some API when installing stuff
> > to a path or opening that path.
> If the API is done right (ie translation is based on the user running
> locale, not the hardcoded translation inside the app), it should be a
> problem.

But the point is that they won't do it right (they won't use the API or
symlinks that you offer). The effect of developers not doing what they
are told is worse if you translate filenames than if you translate UIs.

> I'm not saying translated on-disk folder are THE solution, but unless we
> have a way to have translated folders behaving just like other folders
> in all applications, it is not a too bad solution.

We can get almost all applications with a freedesktop spec adopted by
GNOME, KDE, and OpenOffice.

> > > Con :
> > > -the english names were always visible, even in non english locale
> > 
> > Why, if you "only display localized names in the UI"?
> Because we couldn't hide those directories :

>From what? The shell. Where did the user see them as non-translated?

>  they were created in HOME
> directory, using .hidden hack to hide them in nautilus/konqueror would
> have added other problem ("why do I see stuff with ls / whatever stuff
> might use and I don't see them in nautilus ?") and moreover, removing
> translated name would not have removed the untranslated folder.
> But as I said, it was our first implementation. We learn the hard way ;)

Murray Cumming
murrayc murrayc com

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