Re: Special folders in gnome
- From: Frederic Crozat <fcrozat mandriva com>
- To: desktop-devel-list gnome org
- Subject: Re: Special folders in gnome
- Date: Fri, 13 Jan 2006 15:23:46 +0100
Le vendredi 13 janvier 2006 à 14:56 +0100, Murray Cumming a écrit :
> > > > 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
> symlink.
Well, if they don't know it is a symlink, we are almost fine (unless
they try to rmdir it ;)
> > > > 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?
Since 2.8.7, Home and Desktop are no longer translated in the right part
of the file chooser
See for more details
> > > 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
> anyway.
Well, we are reducing this kind of problem when using localized on-disk
name (but OTOH we are introducing other problems).
> 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.
We've just tested here :
-on disk, names are in english
-they are translated in the UI, with a icon for each folder.
-if you rename the folder, icon stays, on disk is renamed but
applications are still able to access renamed folders without any change
at all : if you renamed Music into foobar, iTunes doesn't bother and
still display foobar content.
> > > 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.
If it is in the spec, they will be warned. We just need to decide what
to put in the spec ;)
> > 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.
Amem ;)
--
Frederic Crozat <fcrozat mandriva com>
Mandriva
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]