Issue 1035

Reassigned to Falko.

Remark: In my opinion, switching the language WITHOUT changing the keyboard 
settings is something that affects fat more people than those who have to swich 
the keyboard (Russian, Greek, ...) or use (varios Input method engines (IME) for 
Japanese, Chinese, Korean. than those who swich between different latin/western 
languages (nglish/Frensh/German/Swedish/Spanish...). 

Nevertheless, an easier switch (or toggle) between languages sounds useful.

>Remark: In my opinion, switching the language WITHOUT changing the
>keyboard settings is something that affects fat more people 

Of course, there must be the possibility to change the language without 
changing the keyboard layout (e.g. for typing English with German keyboard 
layout). But when I have to change the keyboard layout in any case it would be 
nice if the language setting would be changed at once.
(This affects not only Russian and Greek but also most European languages that 
use diacritics like French (there isn't a "c cedille" or a "e diaresis" on a 
German keyboard!), Danish, Swedish, Czech, Polish and so on - the only language 
that you can type with any Latin keyboard layout is probably English!)

.

changing QA contact from bugs@ to issues@

I like this feature, but please make it an option. I hate the fact that I can't write in 
English in Word when my keyboard is set to Italian. I do use some of the extra stuff in the 
International layout even in English, and I can't when in Word. I understand it would 
really help a lot of multilingual writers, but make it configurable (all automatic 
stuff should be made optional).

FT->CP: Can we support this feature for _all_ platforms?

nope, on Unix I see no chance

Duplicate

*** This issue has been marked as a duplicate of 21019 ***

closed

SBA: Reopened. Issue 21019 solves the problem for CJK and CTL languages, but
does NOT solve the problem with Greek and Russian (Both are considered Western).

SBA->FT: I found this one while closing issue 21019. The problem of writing
English+Greek and English+Russian is not touched with that one.
 
Target set to "OOo later".

Please note it's not only for "English+Russian", "English+Greek", the issue is
applicable to "western-only-keyboard-language-pairs" also (e.g. English+German
or English+Latvian), so there shouldn't be any artifical restrictions (like
"let's try to guess what's western language and skip language selection for it")
when implementing a solution. More reasonable seems to have a kind of checkbox
"Use language retrieval from IME for all languages" as opposed to "for CJK/CTL
languages".

How would you decide what langugae this text is? (I'm writing english with a
german keyboard layout) -> not possible (both use latin alphabet/letters).

> How would you decide what langugae this text is? (I'm writing english
> with a german keyboard layout) -> not possible 
> (both use latin alphabet/letters).

If you don't switch the keyboard layout, it is clear that OOo cannot guess a
language switch. In this case, you will have to manually mark the text as English.
But English is really an exception, because it uses only plain ASCII characters
and thus can be written with almost every other Latin keyboard layout. But
imagine other European languages that all have some special characters (French,
Danish, Czech, Polish, ...), you can't write them with a German keyboard layout.
And when you nevertheless have to switch the keyboard layout it would be very,
very nice if the language in OOo would switch, too (because it's simply annoying
to need to switch both: the input locale for keyboard layout, and the language
in OOo)
Another solution for English would be to assign the German keyboard layout to
the English input locale (this is possible at least in Windows). You could then
switch the input locale to English, continuing to type with the German keyboard
layout, but OOo will correctly recognize the language as English.

Exactly, Christoph, it's one way of utilizing this functionality, and it's OK.
Another, nearly the same, way is (I use it personally) to utilize single
"US-International" as the keyboard layout (you can get most diacritical marks
with it) assigned to different languages (English, Estonian, German) and it
works also.

Cloph, for users like you there are two options: either not to use this
functionality (remember I strongly suggested this to be "checkmarked" in
options) or to change the working habits (e.g. as described above, or for your
particular case to create add one more input locale "english" with the same
german keyboard layout if it's your typing preference). After all, the whole
thing is an issue for  those using multiple languages extensively, not "twice a
year".

Done for Windows. Currently not possible under Unix.

,

Any idea when this functionality will be released for Windows?

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

why is this issue fixed/closed?

there isnt a solution to format word by word the text, its very inconvenient

at least, a macro or whatever doing this would be ok

How come it can be closed?
This feature either is not implemented or not working in m178.
Please reopen and set to higher priority.

Although this is closed, I believe it is still not implemented? I do not see it
working in my OOo 2.03.

There is a comment that this wouldn't be possible to implement under Unix. *
What specifically hampers this implementation? * If I knew the problem, I could
devise a solution.

I have added a comment to issue 67134
(http://qa.openoffice.org/issues/show_bug.cgi?id=67134) that could offer a
partial solution even under Unix. (that issue discusses basically the same
problem as this one.)

When we change the locale and write in a language with special characters (like
russian, greek and many latin languages), OOo could scan the word for such
unicode characters and if it detects one, the language could be assigned. (this
does NOT work on every word, unfortunately, as many words in latin languages do
not contain such special characters, but it would be fine for greek and cyrrilic).

Also, I posted a remark (see issue 67134), that in order to make language
assignment more easier and more accurate, there should be the possibility to
select - before writing the document - what languages will be used in the
document, e.g.
 - English, French, Russian
  -- so every word in cyrrilic would be easily assigned the Russian language
  -- any word having some special unicode characters would be French
  -- and everything else would be English
  -- of course, there will be some mal-assignements (fr => en), but it would be
easy to implement on every OS (write a short subroutine in the spellchecling
engine that detects eventual special unicode characters) AND implement a simple
GUI where the user can select the languages that will be used in the document.

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

Reopening as suggested by FME.

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

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

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

As far as I can understand, judgment on the importance of this "language
selecting" issue highly depends on the background of the commenter.

You will hardly find any greek writing person who won't put this issue as one of
the Top 3 inconveniences of OO. 

On the other hand, people from latin writing countries (for example germans who
write every now and then an english word) will find issue 1034 far more
important than this one.

As Falko is no longer working on OOo I take this issue over for the moment

Most western and central European languages use diacritics and/or letters which
not only are not found on an ASCII keyboard, but which differ from each other
sufficiently so that even better equipped keyboards, like those with a variant
of Scandinavian orthography, which I use, lack access to many necessary symbols.
Try writing, for example, the name of the eminent Czech sinologist, Jaroslav
Průšek, whose centenary we celebrated last year, without resorting to time
consuming work-arounds ! The ability to change keyboard settings directly from
the keyboard, as can be done in Word, would be a great help to many of us, and
flatten the learning curve for new users....

Henri  

I think we should bring this to an end in 2.3 - in either way. 

TL: reassigned to me. Should be implemented along with the language status bar
control that is part of this years Google Summer of Code.

Some thoughts about the feature.

We already have it for asian and CTL languages. It's clear that the feature is
also very useful for languages like russian or greek where the assigned keyboard
layout contains totally different characters and symbols than the english one.

This is different to some western languages like e.g. german. I for myself never
switch to an english keyboard to write english documents. The german keyboard is
well suited for them and switching it would just confuse my fingers. 

So automatically switching the document language to "german" just because I have
the german keyboard layout would be annoying for me. Means: it must be possible
to turn this feature off.

The question is: what should be the default? Having a language specific default
for a configuration setting is something we should avoid so perhaps the default
should be "on" in all cases. I think the competition does the same.

mba, you just need to have switchers that define (langage, IME/keyboard) duplets
and define the same keyboard for English and German in your switcher (that's how
windows works BTW). + allow tagging manually a text span with another langage
(for people that write short quotes in another language but do not use it enough
to justify configuring a separate (langage, IME/keyboard) duplet)

Problem solved

Also if OO.o is actually made language aware it won't need to check documents
with every spellchecker available, just the right ones, and resource use and
speed will improve.

In my example of writing english and german documents with the same keyboard no
tricky configuration could find out which language my document should have.
That's something I have to select manually. 

So we have two concurrent ways to determine the document language: automatically
and manually. We must find the best way to resolve this concurrency. "Best"
means best for the users and best for the deployment/configuration.

Thanks for your suggestion. We will consider it as one of the possible options
to see which one is the "best" as described above.

You didn't read what I wrote.

To handle your case you lets the user define two "keyboards" with the same
physical layout but one associated with the EN_US language and the other with
German.
So when the switch happens you change the langage mode but not the physical
layout itself (and yes that means you have to press the switch key just to to
inform the app you changed language even if you don't need the physical langage
switch)

That's how it works under windows now. That's the only sane way to have it work
accross apps (please do not even consider an OO.o-specific switcher)

Under UNIX/Linux you probably need to talk with the xorg guys to add a langage
info in addition to layout info in xkb, or ask svu to have the GNOME keyboard
switcher emit a d-bus langage notification

You didn't read what I wrote.

To handle your case you lets the user define two "keyboards" with the same
physical layout but one associated with the EN_US language and the other with
German.
So when the switch happens you change the langage mode but not the physical
layout itself (and yes that means you have to press the switch key just to to
inform the app you changed language even if you don't need the physical langage
switch)

That's how it works under windows now. That's the only sane way to have it work
accross apps (please do not even consider an OO.o-specific switcher)

Under UNIX/Linux you probably need to talk with the xorg guys to add a langage
info in addition to layout info in xkb, or ask svu to have the GNOME keyboard
switcher emit a d-bus langage notification

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

.

Changing target. The time until OOo 2.3 is to short for this since this one is
to be fixed along with issue 77208 which will still need some time.

I just noted that we should not yet use the target OOo 2.4.  Thus changing it to
OOo 2.x.

To avoid misunderstandings: we still work for finishing this in 2.4, the target
is not set to that release now just for formal reasons (no comment from me about
that :-)).

We had planned 2.3 first but now we think that we will not finish implementation
until July 5th (the last date for new features and enhancements).

My example wasn't good enough to explain the real problem. So I took some time
to rethink everything to avoid endless discussions just because I overlooked
this and that. I hope I'm done now. :-)

I still think that things are not so easy as they seem because we have to deal
with two concurrent ways to select a "document language". So I tried to define a
workflow that takes the resulting problems into account and hope it makes some
sense.

I don't have a problem with the basic requirement to switch the language in OOo
when the input locale is changed, but wouldn't it be nice to also have the
language of a freshly created document taken from the input locale? Perhaps it's
not nice, it's what people expect?

If you agreed to that - now about the problems we get from that.

After a default (western?) Windows installation no additional input locales are
configured and there is no toolbar to select one. If we always took the language
from the input locale the user would be stuck with the single system language
and won't be able to select anything else as default document language in OOo,
perhaps without even knowing why! The same is true if more than one locale is
configured in Windows but the toolbar is not visible (or the user is not used to
use it).

In this case it would be better to stick with OOo's setting for the default
document language. To have a consistent user interface OOo then also should try
to switch the input locale of Windows so that it matches the OOo setting. The
competition does exactly this. Whatever input locale I have set on my Windows
installation Word always switches it to "DE" as this is its default document
language. 

To make it clear, I don't talk about the language settings in existing documents
or language settings the user has set on character level inside OOo, I'm only
talking about the default document language. According to this OOo will try to
change the input locale when it starts and when the default language is changed
in the "Options" dialog.

BTW: for those who don't know it, Windows remembers the input locale on a per
process base so any change made to that setting in OOo will not influence the
setting for other processes.

We could also workaround the problems by adding the configuration setting I
suggested. As I don't see any reason to make the "switch" feature optional
(thanks to nmailhot for correcting me in that point) I would only make the
"default document language" part optional. The default should be "off" then and
if a user switches it on the listbox for the selection of the document language
should become disabled. As then the user is aware of the feature we even could
refrain from adjusting the input locale on startup.

Seems the future of Unix input is IM-BUS
http://www.freedesktop.org/wiki/TextLayout2007/

OO.o developpers should talk with James Su and check IM-BUS will provide enough
info to OO.o so stuff like dynamically changing the input spelling language works

As feature freeze for 2.4 has passed: target 3.0

As the time for UI freeze has come I think we should do it the esay way: enable
the feature we already have for asian and CTL language also for western
languages. It still leaves some room for improvement but it generally works and
it is not UI relevant as no UI changes are necessary.

A beta should be time enough to see whether some unexpected problems might happen.

It would be nice to test on a machine where only one input locale exists (so no
language toolbar is present) and this locale differs from what the user wants to
use in OOo. Admittedly this should be a very rare case.

Here's a description of the enhancement.

Given is a Windows computer with at least two installed languages, e.g. English
and Russian. 

When a new text document is opened, it gets the input language from the system.
This is currently not reflected by the language status bar control. I think this
is a bug (but not a new one as this can be seen in the current version already
if the second language is Asian or CTL). But as soon as the user types, the
language is used and then also displayed in the status bar control.

When the user switches the input language OOo will take over the new language,
but again this is not immediately shown in the language status bar control (same
as above). As soon as the user starts typing the correct language is shown. If
the user didn't type but move the cursor, the new language is discarded. This is
in line with other attribute changes at the virtual text position created by a
cursor. Again this is what already happens in case of Asian and CTL languages,
nothing new.

fixed in cws sw30bf02

Good news!
What is the target milestone for integration and how do non-developer types 
see the code?

Thanks a lot.
WBR,
KP.

Seems that I was too optimistic. :-(

Some more in-depth testing on different systems revealed a nasty problem that
will drive users nuts. On a Windows computer with only one installed language
the language bar is not available and the input locale always will be the
default language. This is a very common case for a lot of Windows installations.
By default my German Windows XP did not install any other languages. As I use to
write most of my documents in English, I have told OOo that this is my default
Western document language (Tools-Options). And everything worked as expected. 

Now, with an input locale always being German, the OOo setting is completely
ignored! Moreover, even if I recognized this and immediately corrected the wrong
language attribute for the text I had entered in a new document, any further
text again would get the wrong (standard input) language.

In short words, the reason for the problem is that the feature makes a lot of
sense for languages that always use their own keyboard but maybe not for others.
People writing English documents will not need a different keyboard layout if
their default layout is any other Western layout (French, German, Italian etc.). 

So users must be able to disable the feature (or even better, it should be
disabled by default but could be enabled by users aware of the language bar). As
UI freeze has passed, I'm afraid we can't add a switch or so. If no additional
UI changes are possible this had to be postponed to 3.1. In case you don't
understand that: text in the UI must be translated and in such a huge project as
OOo this must be well organized and only happens in fixed time periods that are
defined quite some time before. 

Perhaps for the time being we could add a table of Western languages in the
code. If a language from this table either is the system input language or the
OOo language attribute at the current cursor position, the feature will be
enabled automatically, otherwise disabled automatically. 

(As the described problem doesn't seem to exist(?) for non-Western languages we
can keep everything as it is for Asian and CTL languages.)

That means, if the input language is e.g. Russian and OOo's language attribute
is English (or vice versa), the language attribute will be changed
automatically. OTOH, if the input language is German and OOo's language
attribute is English (or vice versa), the input language will be ignored completely.

So we could compile a list of Western languages where the feature will be enabled.

Comments, anyone? Is there an alternative to this list? And if no, which
languages should it contain? 

Please make sure that you really understand the problem even if it doesn't
concern you. We already had enough talking at cross-purposes here.

> People writing English documents will not need a different keyboard layout if
> their default layout is any other Western layout (French, German, Italian
Right. However, people writing (usually) French documents (and using French
keyboard by default) would probably use another layout (German) to write
documents in German (just for umlauts or sz), for example. I'm afraid you tend
to get into the "US trap of ASCII127" here as English is the least common
denominator for all Western languages ;-).

> Comments, anyone?
Can your suggestion be re-stated and generalized as follows: "For the system
input language to be auto-applied to the text being entered, the two languages
must belong to different scripting groups"? Here "scripting groups" at the first
glance are similar to Western-Greek-Cyrillic-Turkish-Hebrew-etc fonts division
in old MSWord and in current WordPad. (Just a little background for pure-western
people: like "western" is a basis for English, French, German etc having
different national keyboard layouts, so is "cyrillic" for Russian, Ukranian,
Bulgarian and others; I suspect that the same situation might be with "arabic"
at least.)

If it's correct then I suggest that the "disable the feature" logic above is
applied only to systems with only one input locale installed, as users that have
installed more than one locale probably both have "more complex needs" and are
advanced enough to install more input locales and be able to switch between
them. Consider yourself, but in situation where "usually 50% of your document's
contents is in English and other 50% is in German (intermixed!)", not "99.9% of
your documents and their contents are in English, irregardless of your only
input locale being German" and you still want spellchecking to work properly.

Of course, for any "list-based" implementation the evil is that UI changes have
really been frozen now, so user cannot disable this feature even if he finds it
working improperly; and we have to be ready for being blamed (the system wants
to be smarter than us again!), maybe not without a reason ;-).

OFF: I'd rather say that the whole "default language" idea is a little bit
confusing...

Now I see the problem.
I suggest enabling our new behavior only when user has two keyboard layouts 
and one of those languages is set in Office as default for western languages.

That would be quite complicated as currently there is no code that gives
information about the installed keyboards. I'm now interested in a solution that
can be used in the beta (and so time is limited). The new behavior will work if
one of the involved languages needs an own keyboard - thus me idea to create a
list of languages where the new behavior is used.

There's another interesting part in this issue.

If the user switches his keyboard to e.g. Japanese and puts the cursor into an
english text, OOo will still remain in the "Japanese" setting. So any text
entered at that position will be Japanese (characters from keyboard as well as
OOo language attribute).

Word switches to English instead but also change the input language (otherwise
we would get English attribute but Japanese characters). I think that this is
better under most circumstances. So in the long run we must think about not only
reading but also setting the input language.

>> People writing English documents will not need a different keyboard layout if
>> their default layout is any other Western layout (French, German, Italian

> Right. However, people writing (usually) French documents (and using French
> keyboard by default) would probably use another layout (German) to write
> documents in German (just for umlauts or sz), for example. I'm afraid you tend
> to get into the "US trap of ASCII127" here as English is the least common
> denominator for all Western languages ;-).

It's not a trap, it's a fact. One must see the problem from a user's side, not
from a technical perspective. And the situation I described is very common.
There are a lot of people writing documents in their own western language and in
English and I doubt that many of them will switch keyboards for that purpose. Of
course that may be different for people writing in French and German, but as we
can't please all here we must find a solution that does the least damage.

> Can your suggestion be re-stated and generalized as follows: "For the system
> input language to be auto-applied to the text being entered, the two languages
> must belong to different scripting groups"? Here "scripting groups" at the 
> first glance are similar to Western-Greek-Cyrillic-Turkish-Hebrew-etc fonts 
> division in old MSWord and in current WordPad. (Just a little background for 
> pure-western people: like "western" is a basis for English, French, German etc 
> having different national keyboard layouts, so is "cyrillic" for Russian, 
> Ukranian, Bulgarian and others; I suspect that the same situation might be with
> "arabic" at least.)

I'm not sure if I understand correctly. OOo already has scripting groups "CTL",
"Asian" and "Western". While the first two already have the automatic input
language selection we are currently discussing the first. If your proposal is to
divide that into sub groups "Western", "Greek", "Cyrillic" and "Turkish": yes,
that would be what I intended to get. 

> Of course, for any "list-based" implementation the evil is that UI changes have
> really been frozen now, so user cannot disable this feature even if he finds it
> working improperly; and we have to be ready for being blamed (the system wants
> to be smarter than us again!), maybe not without a reason ;-).

I agree; OTOH it was hard to find a proper solution for the necessary UI. I
tried to move the discussion forward at several places but it got stuck. The
main problem was that people asking for the feature failed to see the problems
it created for others and so we have been talking at cross-purposes for quite
some time now.

I will add a configuration setting to switch the feature on and off regardless
of the list; in the worst case we could provide an extension to use it. 

> OFF: I'd rather say that the whole "default language" idea is a little bit
> confusing...

Not all operating systems offer input locale switching, so OOo must have some
means for that. The "default language" is what we provided, and we still need
that. The confusion is present only for systems where something better is available.

As I still don't have a better idea I will start with enabling the feature for
all cases where either the language attribute of OOo or the input language from
the OS belong to one of the following groups:

(1) Asian script type
(2) CTL script type
(3) Non-Latin keyboard

In these cases the OOo language attribute will be changed to the input language.
If both languages are not in any of these groups but to

(4) Latin keyboard

the language attribute from the OS will be ignored. 

I know that it could be possible to get more into details in group (3) - perhaps
we could also do it for e.g. Latin-3 or others - but to avoid damage for
unprepared users I would like to start with undoubtful cases.

I'm still looking for a good method to match ISO locales to these groups.
Perhaps we already have some code lying around doing this but in the worst case
I would need to write it by myself. 

I think I've got it.

If the user switches the language in the language bar, this setting will be used
for following text input *always*. If a new document is created or loaded, the
language from the language bar is used for following text input also except for
onee case:

- when the selected language is a "western" language and
- OOo's language attribute is "english" and 
- the text input does not belong to the greek or kyrillic UnicodeScript type. 

This looks like a good compromise to me.

In future versions this should be replaced by a new language selection UI in
tools/options.

For QA:
On Windows the language used for the current keyboad input always is the
language that the Windows language bar shows. There is only one exception: until
the language bar is switched for the first time any "latin" language coming from
it is ignored in case the OOo default western text language is English.

Beware: the language status bar control currently shows the language of the
selected text or - in case the cursor is at the end of a paragraph - the text
before the cursor. So in case the system lnaguage overwrites the OOo setting
this won't become visible before text is entered. This is not a new behavior,
this was already implemented that way for CTL and Asian languages.

Reassigned to SBA.

Verified in CWS sw30bf02.

OK in DEV300_m20. Closed.

SBA: I had to close issue 91536 as invalid because of this new behavior. It
looks as if the current behavior does not serve all user scenarios. 
Note: Not really unexpected, see MBAs comment from March 6th 2008  :-)
So I wrote issue 91552 to adjust this behavior via UI.

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

Issue 100762 is relevant, too.

       HI support of Open Office this is what I get  "˜lá/¾�ñŒ#ÿyIlD·]MÚ0Š†zòf¿" when I open up a document,,,I do not understand or know how to make the correct adjustments in order for the typing language to be in English.