Apache OpenOffice (AOO) Bugzilla – Issue 58856
locale-fallback fails sometimes (composed characters/dead keys don't work)
Last modified: 2013-07-30 02:17:27 UTC
Hello, 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
Reassigned to ES.
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.
@us: 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 place) 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
*** Issue 58830 has been marked as a duplicate of this issue. ***
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.
"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 ?
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 manager." 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.
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.
target
Reset assignee on issues not touched by assignee in more than 2000 days.