xffm updates, i18n still broken

[edscott wilson garcia]

El mar, 08-04-2003 a las 14:59, Olivier Fourdan escribió:
> Oh, and I forgot. As for the treeview, it takes its data from the
> system, so when showing dates, it might get wrong UTF8 (as data that
> come from the system seems to be locale dependent) and doesn't show!

Hmm... If the "ls" command works, the dates should work since the code
for the date parsing was "contributed" by the same guys who wrote
GNU-ls. It works on my box even when there are no po files for xffm.
Benny changed some stuff from the ls code, but it still seems to work
fine here. Please note that when changes are introduced to the format of
the settings file, the version number is incremented and doing so makes
the default configuration return. In the default configuration neither
date, size, owner or group appear, but can be toggled on with alt-D,
alt-S, alt-U or alt-G.

> 
> I think data from the system should be converted to UTF8 so they can
> show in the treeview (don't know how though, I used
> gdk_text_property_to_utf8_list() in xfwm4, but that's for text
> properties)

I do some checks about the codeset and then use g_convert(). It's in
libs/misc.c. I'll make sure the date column is utf-8 converted in my
commit later tonite. Although it might not be necessary, it won't hurt
either.

saludos,

Edscott

> 
> Cheers,
> Olivier.
> 
> 
> 
> On Tue, 2003-04-08 at 21:52, Olivier Fourdan wrote:
> > Hi Edscott
> > 
> > On Mon, 2003-04-07 at 05:16, edscott wilson garcia wrote:
> > > I've changed it to a subroutine which checks if it is valid utf-8 before
> > > acting. It might work ok now. 
> > 
> > Nope. the fix is only partial.
> > 
> > The messages in "Book", "Search", etc. still show wrong UTF8 (basically,
> > UTF8 is not treated as UTF8 and shows wrong sequence of weird
> > characters)
> > 
> > The problem is even worse in xfdiff4. I think it might come from the
> > libs, I'll dig into this.
> > 
> > Another annoying problem is that not all messages are marked for gettext
> > as it seems. For example, none of the entries in "Option" menu are
> > marked, at least, none show in the po file. This is very annoying
> > because translators have to redo the translations again and again, each
> > time new strings get marked :(
> > 
> > At last, I'm very annoyed with the use of all these environment
> > variables. What's the point of having a graphical file manager if the
> > user has to set a bunch of environment variables from the terminal to
> > get the desired behaviour ? As for using a tooltip in the menu to get
> > the explanation of the variable, it doesn't make sense from a GUI
> > usability point of view. Menu entries are to be selected, users don't
> > expect to wait a tooltip to get help from the menu...
> > 
> > As for the use of a variable to store SMB login/password, well, it's
> > very unsecure and I would avoid using SMB browsing in xffm if I had to.
> > There might be another way of doing this in xffm, but I could not find
> > it.
> > 
> > Cheers,
> -- 
> Olivier Fourdan <fourdan at xfce.org>
> http://www.xfce.org
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://moongroup.com/mailman/listinfo/xfce4-dev
>