Re: Translations of folder names - two proposals
- From: danilo gnome org (Danilo Šegan)
- To: Alexander Larsson <alexl redhat com>
- Cc: Havoc Pennington <hp redhat com>, Alan Cox <alan lxorguk ukuu org uk>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>, Jamie McCracken <jamiemcc blueyonder co uk>
- Subject: Re: Translations of folder names - two proposals
- Date: Sun, 12 Dec 2004 17:30:19 +0100
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]).
Cheers,
Danilo
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]