xffm updates, i18n still broken

[edscott wilson garcia]

El mar, 08-04-2003 a las 14:52, Olivier Fourdan escribió:
> 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)

I guess you refer to non-root level entries. I only fixed the root level
entries. I'll put in a fix for the "dummy" entries (where the temporary
messages appear). FYI, the problem resides in the g_locale_to_utf8()
function, because if the locale is not utf-8 (as in fr_FR), then it just
screws up the utf8 text. 

> 
> The problem is even worse in xfdiff4. I think it might come from the
> libs, I'll dig into this.

Ok. I'll leave xfdiff to you and concentrate on xffm. There is an even
worse problem with the codesets which I am working on: if the remote
server is samba, the codeset is different from that of windows.
Fortunately there is a way to tell the difference before displaying the
text.

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

It seems libs/preferences.i is missing from the po/POTFILES.in file.
I've added it and done a "make update-po" but have not yet done a
commit. I'll be doing a commit in two or three hours fixing the latest
codeset issues, so if you want to commit the po/POTFILES.in before that,
please do.

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

That would just be an alternate way. The actual intention is to use the
xfce-mcs-manager to set the values on the fly. When xffm receives them
it will do a setenv() or equivalent.

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

Right. I agree. What I want is to click on the item and have the text
appear in the diagnostics window. But since I didn't have enough time, I
put it in the tooltip so I wouldn't forget the text.

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

The environment variable is only for use in secure systems (or for users
who could care less). Otherwise you should not use it and just wait for
the password challenge dialog to pop up.

saludos

Edscott

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