Re: Translations of folder names - two proposals
- From: danilo gnome org (Danilo Šegan)
- To: Havoc Pennington <hp redhat com>
- Cc: "desktop-devel-list gnome org" <desktop-devel-list gnome org>, Alexander Larsson <alexl redhat com>, Alan Cox <alan lxorguk ukuu org uk>, Jamie McCracken <jamiemcc blueyonder co uk>
- Subject: Re: Translations of folder names - two proposals
- Date: Sat, 11 Dec 2004 21:31:49 +0100
Today at 19:06, Havoc Pennington wrote:
> That doesn't seem related to what I'm saying. What I'm saying is that
> the way the user believes it works need not have anything to do with how
> it really works. Alan is saying that we can't "lie" to the user, they
> have to see how it really works. (Which, ad absurdum, means we need to
> hand them an assembler... but even not going ad absurdum, it is
> generally considered a first principle of design that the implementation
> should not leak into what the user has to think about.)
I agree on this (as I already said), but the proposed gettext()-based
implementation creeps me out. I don't want translated names to sit
in some file filesystem.mo lurking who knows where.
I want us to push for folders with translatable properties, but
while we're doing that, why don't we make it work for any folder/file
on the system?
[No, I don't consider updating filesystem.mo manually to be "make it
work for any folder/file on the system"]
Yes, MO files are pretty fast (without hash table O(log n), with hash
table O(1)), but they're not really manageable. What I want as well
is API set_display_name_for_path(path, language, displayname) along
get_display_name_for_path(path).
If, OTOH, we're going for half-solutions, I prefer the symlink method.
Cheers,
Danilo
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]