Re: Displaying file/folder translations
- From: danilo gnome org (Danilo Šegan)
- To: desktop-devel-list gnome org
- Cc: Mike Hearn <mike navi cx>, Alan Cox <alan lxorguk ukuu org uk>
- Subject: Re: Displaying file/folder translations
- Date: Thu, 02 Dec 2004 12:54:27 +0100
Hi Jeff,
Yesterday at 22:55, Jeff Waugh wrote:
> <quote who="Danilo Šegan">
>
>> Though, http://acl.bestbits.at/ mentions patches for NFS (this probably
>> means that both NFS server would have to be patched; and not all NFS
>> servers are running Linux kernel). NFS4 (not really something we'd
>> consider "widely deployed") ought to support them as well.
>>
>> Still, this probably rules xattrs out as something to depend on.
>
> See, even with xattrs, you're still relying on some piece of software to
> write those translations - unless you're pushing the reponsibility back onto
> users! Eeek. So you end up requiring some GNOME library to write the
> translated stuff to disk, instead of just displaying the translation in the
> UI.
Uhm, unless you're aware of some magical powers that I'm not, how do
you "just display the translation in the UI", if it's nowhere to be
found on disk? :)
Translations are always on disk, whether it's in gettext .mo
files, .desktop files (in Gnome, these're usually in both .gmo and
.desktop files), or discussed .directory files or GConf keys.
Instead of several disk seeks more, introducing parsing overhead,
we'd get them where we want them: right next to the name itself.
So, this was a discussion on *where* on disk to store the
translations, and making "some Gnome library" do it in EAs (if
available) is exactly what I had in mind. It'd be on another Gnome
library (gnome-vfs) to read these and offer them to a user.
> And you're also relying on all of your other tools to use those EAs, so
> you need to patch everything from ls up. So, like when people argue against
> doing inline translations of standard file locations in a GNOME library,
> you're back at square one. :-)
Now, instead of putting them in .directory files which will
inevitably slow things down, it's much better to have them in EAs
which are much easier to parse and set (not to mention as fast as
filesystem can do them), and to embrace as standard for console
utilities (we simply have to start somewhere).
As I said, we've been waiting for this too long, so I think going for
a best possible solution, provided it will work in the near future on
all relevant systems (including home dirs over NFS), is the route to
take. The only downside is that we can't warrant that EAs will
actually work on "all relevant systems".
Cheers,
Danilo
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]