Re: Various issues for emelfm2 0.1.7

On Tue, 2 May 2006 13:24:05 +0200
Marcus von Appen <mva@xxxxxxxxxxxx> wrote:

> On, Sun Apr 30, 2006, tpgww@xxxxxxxxxxx wrote:
> 
> > On Thu, 27 Apr 2006 23:31:33 +0200
> >
> > Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
> 
> [...]
> > > * Localization issues in multilanguage environments:
> > >   Given the case a user wants to use emelfm2 in various languages, he
> > >   will have many troubles with emelfm2's toolbars:
> > >        http://sysfault.org/emelfm017_i18n.png
> > >   
> > >   How to repeat this error:
> > >   * Start emelfm2 in you default locale.
> > >   * Quit it and set your locale to a different one (I simply exported
> > >     LANG as C, but it also works fine with setting de_DE.UTF-8 to
> > >     ja_JP.UTF-8 and other combinations).
> > >   * Start emelfm2 again and look at its reordered layout :-).
> > The question is: what is the best way to deal with this ? I don't much
> > like reverting to english-only config data. To manage different locales
> > ... some things in a config file are easy to "un-translate", others are
> > hard, some are effectively impossible. So on-the-fly re-translation is
> > not an option either. Perhaps it's best to simply flag a config file
> > for a locale (name it config.$LANG or .$LC_MESSAGES or ?) and always
> > try to use the one for the currently-active [variable], and if none
> > found, revert to default settings.
> > 
> > What do people think ?
> 
> That sounds like a solution, which should be integrated quickly. This
> however will cause the application not to use your set configueation, if
> you are changing the locale. Instead you have to adjust anything again,
> which can be pretty annoying.
> In my opinion however, using a locale-dependant configuration is a
> critical problem. I wonder why this has benn introduced as it is
> unlikely for most users to hack around in an (user-)application
> configuration anyways. Personally I prefer the opinion
> 
>          "If it is not worth to be in a configuration dialog, it is not
>          worth to be in a config file, too."
> 
> Therefore I cannot imagine, that there are some configuration options,
> which are only reachable via manually editing.

The data in a config file is all exposed in the config dialog. That's the basis 
of the problem !

> I would say, keep the configuration file locale independant. If users
> want to hack around it, you can use e.g. translated doc strings within
> the configuration, but do not localize the configuration options
> themselves as it is likely that they cause more issues than they solve
> (as above).

> > >   The output issue is another case, which I only encountered in
> > > cases, where a shared object loaded by the program wants to write
> > > something to stdout.
> > Can you recall what the problem was, and where ? Probably due to the
> > bad regex just mentioned.
> 
> Given the case you have an application 'Foo', that links against the
> shared library 'bar.so', which e.g. produces some debugging output, that
> is sent either to stderr or stdout, you mostly will not see that output 
> produced by 'bar.so'. You only will see it at the termination of the
> program, if you are lucky, but it is not guaranteed (I could not figure
> out, on which criteria this depends).
> 
> In my case, it was an shared object library, which was used as python
> module. The main python script produced the correct output, but
> whenever the shared object library reached a point, where it should
> print something using printf(, nothing happened.
> Instead its output was shown at the termination of the python script,
> but not always.
I see. Sorting that out will require understandings that I presently don't 
have. I'll mark it as a TODO.

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: