Re: Translations of folder names - two proposals

[Havoc Pennington <hp redhat com>]

On Fri, 2004-12-10 at 00:07 +0100, Alexander Larsson wrote:
> 1. The gettext method
> =====================
> 

I still consider this clearly superior from a technical point of view.
The symlink thing has many ways to break. The gettext approach always
works as designed, and I continue to maintain that the design downsides
are non-issues if we have our priorities straight.

It's also pretty easy to change the gettext approach to an alternate
implementation over time; e.g. you could swap in .directory files, a
lookaside table, or whatever. Doesn't have to use gettext. This will let
us address any issues with the particular implementation, such as speed,
if required.

And there's no *fundamental* reason that bash can't be aware of display
names - so avoiding the approach on those grounds is really saying "we
think the bash maintainers will be too stubborn, so we'll work around
them with hacks" - to me if bash isn't easy to use along with the
desktop, then that's a bash problem, and maybe they will fix it or not,
but it's up to them.

The symlink approach violates principles of good design:
 - it's not encapsulated; the implementation is leaked out and 
   essentially cut-and-pasted (e.g. rules for creating it, etc.
   replicated in every script/app)
 - you have to keep the same info in sync in two places
   (symlink target, and actual directory name)

And it's not even clearly easier to use from the shell, once you start
making people deal with the nasty implementation leakage of how to
create and use the symlink. The obvious thing to do will be to use the
translated directory directly... which is what people will do, and of
course that will break. Heck, it's not only what people *will* do it's
what they already *have done* with ~/Desktop I imagine, in existing
scripts and code. And what they have been shown to do on Windows in the
same situation. There's just no reason to believe that people will know
about or use the symlink.

The gconf approach has essentially the same problems as the symlink
approach, though in both cases if you declare that the only supported
access mechanism is to call a g_get_directory (G_DIRECTORY_DESKTOP) then
it's a little bit more encapsulated and that could be nicer.

Havoc