Issue 58856 - locale-fallback fails sometimes (composed characters/dead keys don't work)
Summary: locale-fallback fails sometimes (composed characters/dead keys don't work)
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0
Hardware: PC Linux, all
: P4 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
: 58830 (view as issue list)
Depends on:
Reported: 2005-12-04 17:36 UTC by hoogewoud
Modified: 2013-07-30 02:17 UTC (History)
1 user (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description hoogewoud 2005-12-04 17:36:03 UTC
I use Kanotix and KDE. In all programms such as firefox, kwrite I can write être
(circumflex) or niño (tilde) but I cannot use these signs (dead keys) in
Openoffice 2.0 programms. My keyboard layout is fr_CH and all accents tildes
circumflexes work perfectly but not in OO prorgramms. It is really annoying when
writing in french (the spellchecker sees it correctly however..)
Any way out
Comment 1 michael.ruess 2005-12-06 11:06:40 UTC
Reassigned to ES.
Comment 2 hoogewoud 2005-12-09 21:21:39 UTC
I checked further on found several anouncements on the net that dead keys on
Debian systems did not work under Openoffice  but did work otherwise under other
KDE programms, such as e-mail or Koffice or Kwrite.
I use a Debian system (Kanotix). By the way I have no problem usung OOo with
Suse 10.0 and dead key work with OOo and KDE programs.
Comment 3 lohmaier 2005-12-09 23:11:29 UTC
locale fallback seems to fail on broken distros (mainly debian-based ones).
(Yes, I call them broken. They should not offer non-valid locales in the first

Please check whether you could improve the fallback implemented with issue 16318
/ issue 8988 to be more error-resistant or popup a message requesting the user
to fix his configuration. (check whether the chosen fallback really works)

see issue 58830, issue 52544, issue 56489, ...

@others: please see issue 16318 for details
Comment 4 lohmaier 2005-12-11 18:17:28 UTC
*** Issue 58830 has been marked as a duplicate of this issue. ***
Comment 5 ulf.stroehler 2006-02-27 16:36:15 UTC
if I'm not wrong 'locale fallback' is restricted to the generic plugin hence
would be an enhancement for qt or gtk plugins. Setting Enhancement. A none
existing locale as e.g. 'foobar' shouldn't harm the fallback.

But the idea of the native widget framework was that character input (events)
should be handeled natively by the toolkit (gtk or qt). And if that fails, it
fails the same for OO.o. Not sure whether we really want (or the users want us)
to mess around in the toolkit. Additionally, how should we detect errors inside
the toolkit? And should we really try to be more clever than the user or toolkit?

us->pl: do you see a possibility for a kind of 'locale fallback' in the gtk or
qt plugin? If not feel to close. Thx.
Comment 6 philipp.lohmann 2006-02-27 16:58:11 UTC
"Locale fallback" is a crude workaround around broken locales, nothing more.
However contrary to US's comment the kde plugin uses the generic one for input
(the difference between generic and kde plugin is just the widget rendering code).

In the mentioned issues 16318 and 8988 the solution was to set the correct
locale in the first place, does this solve the problem in this case, too ?
Comment 7 lohmaier 2006-03-07 01:24:40 UTC
pl: see e.g issue 58830:
comment from dusoft Sun Dec 11 06:40:40 -0800 2005
"Problem disappeared when locale is properly set. Please, note that OO should
maybe introduce its own handling of accented chaarcters not depending on windows

I'm pretty sure that setting a valid locale solves the issue - as it did with
the other issues I mentioned.

Giving the lack of a better solution to locale-fallback, that workaround shoule
be more robust/work more reliably hence this issue.
Comment 8 philipp.lohmann 2006-03-07 10:17:00 UTC
Yes, but what does "more robust" mean ? If the locale is set to "C" or "posix",
what should cause us to set it to fr_CH in contrast to he_HW or xy_ZW ?
Currently the fallback is to en_US.UTF-8 which is on some machine capable of
more international input; notably on iiimf systems where you can actually switch
the input method to different input locales.
Comment 9 philipp.lohmann 2006-06-15 15:09:48 UTC
Comment 10 Rob Weir 2013-07-30 02:17:27 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.