Reassigned to Ulf.

I guess you are logged in with "C" locale (pls. state what locale you
are using).
This is a famous limitation (bug) in XLookupString (Xlib function)
that it can't handle composed characters (s. also
http://wauug.erols.com/~balsa/linux/deadkeys/ ).
Now it could be said that every X-application in the world should fix
the bug in Xlib in their code, and many applications (or toolkits)
seem to do so. But that's not the way system libraries are thought of.

The correct way from the user's perspective is to use a suitable
locale (any latin locale should do) to have real access to all latin
characters. The "C" locale is a 7bit ASCII locale and not supposed to
handle more than 128 characters. The german u umlaut is not among them.

Keeping this task though it is actually an 'Invalid' as OOo should
consider to workaround this limitation (users just don't seem to
understand the need of correct locale settings).

Pls. state what Locale you are using.

I've set the correct lang (to de_CH) and then i can enter the
characters 

export LANG=de_CH 
soffice

but it would be the better solution to take the environment the user
selected in its preferences, because a lot of german or swiss users
are set LANG=posix or LANG=C because some applikations didnt work with
other setting and people like me german error messages :-)

> set LANG=posix or LANG=C because some applikations didnt work with
> other setting

If so, that's clearly a bug and should be fixed by those applications.

OOo respects the Locale environment and behaves absolute X-compliant.
Personally I wouldn't recommend using the C locale, simply because of
many default settings working wrong (e.g. many number formats) not to
mention the hassle with text input of extended latin chars this task
is dealing with.

Reopened issue in order to transfer it.

us->cp: you know so well, that many users don't understand resp. are
not familar with the Locales concept on Unix.
Pls. find a suitable internal fallback so that notorious C locale
users will have more fun with composed characters. Thanks.

did you try some database utilities from "i tell no names" vendors ??? 
it didnt work very well with other LANG= settings then LANG=posix. so
i hacked localy the soffice script and set the LANG to "de_CH".

perhaps my idea to set the lang with the environment choosen in the
soffice preferences " Langage Settings ." override the shell value
will be the best solution.... 

apropos.. a small typo in the Country / Language Dialog... 

the country lichtenstein is spelled wrong.. its Liechtenstein... 

for example

German(Lichtenstein) wrong
German(Liechtenstein) correct 

*** Issue 23256 has been marked as a duplicate of this issue. ***

This bug has been around since year 2002. I have seen it affect all utf-8 based
systems, which include Red Hat Linux 8.0, RHL 9 and Fedora Core 1.

If you change the locale to an iso-8859-x character set, it works, however. Then
äöüæøå work perfectly. But this isn't a solution, because the file system uses
utf-8, and using a different character set for OpenOffice.org would corrupt
filenames.

On Fedora Core 1, there is only one application that doesn't do utf-8, and
that's OpenOffice.org. Therefore, this bug is a real showstopper when installing
Linux for those who only need a computer with an office suite.

I think this bug has annoyed millions of people - and they just ditched
OpenOffice.org because of it, without telling anyone.

This is a problem not only on *nix systems.  I have OOo 1.1.1 installed on Win2K Pro 
Japanese.  In every other word processing sort of app I have used, from WordPerfect on 
MacOS 6.x - 7.0, to MS Wordpad or Word on Win2K, Ctrl+"+u would produce ü, for 
example.   
 
But not in OOo.  The only way I can insert such "special" characters in OOo, short of a 
macro, is through the Insert -> Special Characters dialog, a most ineffecient and 
unsatisfying solution.   
 
Given the behaviour users have become accustomed to, and OOo's unexpected divergence from 
this behaviour, I would certainly characterize this failing as a bug.  Issue 3805 was 
reported more than two years ago, but seems to have been closed, despite the fact that 
this is still a barrier to ease of use, and consequently to wider adoption of OOo.   
 
I look forward to OOo rejoining the rest of the world in terms of ease of input. 

according to the announcement on releases
(http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue
will be re-targeted to OOo Later.

I found out how to make it work on my machine: I changed the case of "utf-8" to
"UTF-8" in /etc/sysconfig/i18n, so that my i18n now looks like this:

LANG="da_DK.UTF-8"
SUPPORTED="da_DK.utf-8:da_DK.iso8859-1:da_DK:da"
SYSFONT="latarcyrheb-sun16"

Changing the case didn't have any influence on all other applications, but it
surely had a lot of influence on OpenOffice.org.

> Changing the case didn't have any influence on all other applications, but it
> surely had a lot of influence on OpenOffice.org.

The same problem. da_DK.utf-8 is not defined. It is called da_DK.UTF-8.
So fallback to C occurs. See comments from us above(Additional comments from us
Fri Jul 4 09:03:42)

Other programs ignore the locale "C" or "POSIX".

So the case of the locale /does/ matter.
If da_DK.utf-8 was set by a tool of your distribution, you should file a bug
against that tool.
Example what happens:
[cl@bm617259 cl]$ LANG=de_DE.utf-8 gedit
 
(gedit:2515): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.
[cl@bm617259 cl]$ LANG=de_DE.UTF-8 gedit

the same happens to OOo. (But OOo respects "C" as locale)

(if OOo will use a fallback-locale, it should issue an error message saying that
"the current locale is invalid and thus OOo uses a replacement of <locale used>"
- or similar)

fixed with i8988. We fall back to en_US if we encounter a C locale or an
otherwise invalid locale

send to qa ...

reassign to ulf

set back to fixed

Verified in cws 'vcl29'.

Pls. also note issue 32772 which conflicts with compound characters on
systems/desktop environments which don't have at least gnome 2.4. Repeating the
work around here again: set the environment variable USE_XOPENIM to true. This
would look like the following in a bash:
export USE_XOPENIM=true

*** Issue 37149 has been marked as a duplicate of this issue. ***

Verified in MWS m77.

*** Issue 56489 has been marked as a duplicate of this issue. ***