Re: Translations of folder names - two proposals

[danilo gnome org (Danilo Šegan)]

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).

I can see more problems with this.  Imagine installing software in
different prefixes (eg. your system-provided Gnome in /usr, and your
own in ~/gnome/): apps from /usr will use
/usr/share/locale/sr/LC_MESSAGES/filesystem.mo, and those from
~/gnome will use ~/gnome/share/locale/sr/LC_MESSAGES/filesystem.mo).
Users will experience all sorts of inconsistency (it's not uncommon to
have new translations added between releases).  Will we also be
careful enough not to remove any folder names in the future (if we do
remove them, even though they'll continue existing on users'
computers, they'll suddenly appear untranslated)?

Users are also unable to rename such folders, again unless we add MO
reading-writing magic.

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.

> 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.

Still, I feel symlink method scales better, even though it makes it
harder to fix buggy translations and untranslated names (if user first
runs in English locale or there is currently no translation, she'll
get "Templates", and probably will be scared to try changing it to
whatever she pleases; later when she switches locale or translation
becomes available, the folder will remain "Templates").


OTOH, I'm still of opinion that combining some features of both
approaches (translations external to directory names as in gettext;
accessible and changeable names by users as in symlink method) would
provide best user experience, but no sane approach has been proposed
to do this (from your experience, .directory files are slow, EAs are
not available on all the systems we support,...).


Finally, I feel "symlink method" is closer to solving the problem,
even though I lean strongly for having translations external to
directory names.

Cheers,
Danilo