Re: Translations of folder names - two proposals

Today at 16:00, Alexander Larsson wrote:

> On Sat, 2004-12-11 at 21:31 +0100, Danilo Šegan wrote:
>> 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).
> What actual use case do you want this for? I don't see it being very
> useful, and it certainly complicates stuff a lot. If the user wants to
> rename something they can just rename it.

As I said, I consider filenames on disk to be translatable, so each
can carry a number of translations.  "Renaming" should affect only
current translation (sort of what happens with .desktop files now:
only current translation is updated).

I acknowledge that this complicates things a bit, but not too much
(we might need that even for installation steps of other software
which wants to provide translated folder names using your proposed
mechanism).  Though, it complicates them a lot if we're talking about
gettext as a solution, since it's very bad in that area (it's mostly a
one-way solution), what I am complaining about anyway.

Also, most user-managed files would have only single translation
(i.e. "Annual-Report-2004"), but *some* might be useful to have in more
than one language (indeed, "Annual-Report-2004" might be such a case,
since it might be useable and viewable by more than one person, and
the document itself may contain multiple language versions: think of
how .glade files are translated according to locale when loaded into
Glade even though they're user-managed "documents"; this is a current
special case, but I don't see why wouldn't Gnumeric support it if it
doesn't already [hint: scripting support]).


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