Re: Various issues for emelfm2 0.1.7
- From: Marcus von Appen <mva@xxxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Tue, 2 May 2006 13:24:05 +0200
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.
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.
Regards
Marcus
Other related posts:
