Re: Translations of folder names - two proposals

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

If, OTOH, we're going for half-solutions, I prefer the symlink method.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]