Re: Translations of folder names - two proposals

[Alexander Larsson <alexl redhat com>]

On Fri, 2004-12-10 at 11:18 +0100, Danilo Šegan wrote:
> Today at 0:07, Alexander Larsson wrote:
> 
> > 1. The gettext method
> > =====================
> >
> > const char *
> > some_lib_get_display_name (const char *pathname)
> > { ... }
> >
> > This allows us to translate files in the users homedir, and other
> > files in the unix tree if we want.
> 
> Such *implementation* would be far from perfect.  If folders/filenames
> are actually translated, they're usually translated without their
> prefix.  Your code does ignore the "/home/<user>" stuff, but we're
> still left without a clear way for users to translate their own
> folders. Thus, I don't see this scaling to "other files" except for
> the folders we actually need translated right away (Desktop,
> Templates, Public). 
> 
> Unfortunately, it's not easy fighting with gettext context and tricky
> translations (eg. should "Templates/Graphics" be translated to
> "Templates/Графика" or "Шаблони/Графика"? what if we translators make
> a mistake in "Templates", and not in the "Templates/Graphics"?).
> Gimp has used such style for menus until 2.2 [GtkItemFactory?], but
> it caused many problems for them and translators).

No. Templates/Graphics should be translated to "Графика" only. Its a
mapping from full pathname to basename.

> IMHO, gettext approach would work only for folders Gnome creates
> itself.  If another software wants to make use of this "protocol", it
> would have to do some tricks with filesystem.mo (msgunfmt it, merge
> translations it provides, msguniq it, msgfmt it back).  Standardizing
> it won't solve all the problems, unless we can think of all the
> possible folder names which might need translation before hand.

Thats is the plan. All additions would have to be agreed upon by the
"community" (say the filesystem.po file is a freedesktop module).

> > 2. The symlink method
> > =====================
> ...
> > Advantages with the symlink method:
> > * No modification needed to applications that don't use well known
> >   folders. We might still want to create a freedesktop standard, but
> >   an application not using the spec won't cause problems unless its
> >   also creating well known directories using a different method.
> > * The user can actually manually change the name or location of the
> >   well known folders if he want. He just has to change/create the
> >   symlinks.
> 
> I'd also dislike to see the "symlink" mark on icons representing
> Public, Templates or Desktop.  Special-casing all such folders in
> Nautilus is PITA.

I don't understand this comment at all. The desktop directory is not a
symlink. Why would it have a symlink mark because there is a symlink
pointing to it?