Translated desktop folders in Gnome/Fedora

For a long time Gnome and other desktops have been using an english directory name for the desktop folder (and a few other common directories like music, download and documents). There has been a lot of discussions (read: flamewars) on how to localize these filename. After the last one I’ve finally broken down and done something about this. So, I present to you xdg-user-dirs.

It is a desktop-agnostic (and dependency free) program that is meant to be integrated by distros so that it gets run very early in the login phase. It will then look at the users locale and system-specific default configurations and use these to create a set of folders in the users homedirectory. It also generates (or updates) a user configuration files that points to these directories so that applications can find them.

I’ve also created the gnome-specific module xdg-user-dirs-gtk and a set of gnome patches that integrates these directories into the Gnome desktop. With these in place (availible in the Fedora 7 rawhide repositories now) users automatically get localized folders like Music, Movies, and Documents, plus default bookmarks to these in the gtk file selector. Any changes to these folders (e.g. moves or renames) with nautilus will automatically be updated in the bookmarks and the user directory configuration.

The Gnome integration even detects when you log in with a new locale and asks you if you want to move your directories to the new language.

Its also very easy for the sysadmin to change the default directories created for users (or to disable the whole thing). Just edit a simple config file.

20 thoughts on “Translated desktop folders in Gnome/Fedora”

  1. Sounds interesting. I’m not 100% how it works though.

    Two questions:
    1. What if the dir already exists, and wasn’t created by this program – will it be renamed?
    2. What if the user switches language?

  2. I’m still not yet convinced about translating the name of the directory on the physical storage of the user, the dependency on a tool running at login time being the biggest issue (but also collisions and support for non local storage come to mind).

    but, anyway is a start. :-)

    my plans for switching the file chooser bookmarks to the xbel storage used by the recent files would make it probably easier to update the places.

  3. I’d just assume keep the thing called Desktop and Documents and translate the UI. This is going to introduce all sorts of issues into a distributed network environment.

    What if Documents isn’t really a folder, but a symlink? How will it know if the folder already exists, if it’s in a different language?

  4. MS made this same mistake. Please don’t do this. Keep the on disk storage static and use the UI to emit translations. I do not want to have to call an API to discover the location of Desktop and Documents like on a Windows platform.

  5. Also, what if you log on twice, from two different locations, with different translations? What happens then?

  6. “and asks you if you want to move your directories to the new language”…

    I can imagine this causing a lot of grief for non techie users.

    “What folders?”
    “Move them, why?”
    “What will happen to all my stuff?”

    It’s an implementation detail they shouldn’t be bothered with. If you feel that you absolutely have to bother them… well… maybe it’s something wrong with the implementation. :) Anyway, hope this can be worked out so you don’t have to pester them.

    (Btw, good to finally get some movement on this issue. Keep up the good work.)

  7. Great idea, but why not keep static folders and create localized hard-links on startup? Then we can keep them in some config file for every login session so applications can use them instead.

    When user login with a new locale, we can just create new hardlinks. Once user loggout from every session using previous locale we can remove hardlinks that are not in use anymore.

    Legacy applications will be able to use static folders and new apps can use localized hardlinks and both for legacy and new apps users will be able to open files from localized hardlinks.

    We can even hide static folders from UI if localized hardlinks are present.

    The only problem I see with this is that in legacy applications, user will be able to see both localized hardlinks and static folder and may dare to remove it (as it is the same as content of localized folder) not realizing it’s hardlink. Don’t know how to solve that.

  8. Alex, could you put patches somewhere in bugzilla? Or at least list fedora patched modules.

  9. Seems like some design decisions have been taken with the rationale that more geeky persons who don’t like localized dirs created in ~ can change them after wards etc. (I.e. you don’t bring up a wizard at first login asking where to name the dirs.)

    Something along the similar lines can IMHO be said about asking after a locale change. I mean, why wouldn’t you want the names of the dirs to change?

    Sure, it might break some obscure app or someones script… but why let Joe Averages suffer for that by asking them questions they probably won’t understand? (Just like you don’t let them suffer by bringing up some wizard at first login… let the geeks worry about this one too instead. ;)

  10. Just one more thing to add… If the rationale for letting them choose is that it can potentially break an application that has remembered their translated dir, how are they supposed to know? They probably won’t find out until it’s to late anyway…

    I’ll stop spamming your blog now. ;)

  11. I don’t think this is a good idea.

    It makes support harder, it seems generally prone to breakage, bad things may happen if you access your home dir from computers with different locales, existing scripts and programs may need rewriting etc etc.

    Please don’t do this.

  12. Both translations on disk and english on disk has advantages and disadvantages. This has been hashed out hundreds of times in the discussions i refered to in the post. I will not start a new flamewar here.

    I think Translations on disk is the best approach for two main reasons:

    1) It is fully internally consistent in the normal usecase (i.e. not switching languages every login) since also filenames/paths are translated. English on disk will leak english into the translated UI wherever there is a pathname displayed or entered, and this still happens a lot even though we try to avoid it. (For geeks this is rarely a problem, but for people who really don’t know english this is a problem.)

    2) It is automatically supported by *all* applications. Non-gnome or binary-only applications like acroread will not show your files in a different folder layout.

    I’ve tried to do the design to avoid and minize the problems with the translations-on-disk solution. For instance, its very very easy to access the user setting from a shell script.

    Anyway, we’ve been discussing this for at least 5 years. Even if you disagree with me on details of the solution its clearly better to have *a* solution than to keep discussing for another 5 years.

  13. Yuck.

    Does the FHS allow writing to or renaming files in a user’s private directory (aside from dotfiles)?

  14. I also think this is a horrible idea, and find it sad that this is being communicated in this way, after having been implemented already. What do you plan next: rename /usr to /Bntz in German? Oh no, I just gave you an idea… :-D

    The great thing about *nix file system hierarchies is (was) that you don’t (didn’t) have to deal with arbitrary directory names, this is breaking this property. Despite your claims about it being 100% compatible, it is definitely going to break some applications: in the real world, not all applications use the libraries to do things, nor do they always look up the paths from config files, I’m sure there’s a lot of hardcoded paths out there! Also think of shell scripts.

  15. PS: To get rid of this, run this command as root:
    sed -i -e ‘s/enabled=True/enabled=False/g’ /etc/xdg/user-dirs.conf
    Something tells me this line is going to end up in a lot of third-party RPM spec files…

  16. What about using something like GoboHide that is used in

    I have not looked into much detail, but it appears to be able to hide/alias folders. This way /home/user/Desktop can still exist but be hidden and aliased in non-English distributions. Then all code that assumes that the desktop is called Desktop would still work.

    Just my 2 cents.

Comments are closed.