Issue 67134

OpenOffice.org can work with more than one language in a document, but it does
it not the way you expect. You have to define a paragraph style for the second
language and apply it to the paragraph before you write in that language. Then
OpenOffice.org will use the right autocorrection, spellchecker and so on.

It is a known problem, that OpenOffice 2.0.3 does not show the right language in
the context menu, see issue 66798.

Issue 1035 is about changing the language accordingly to the keybourd layout, so
I set this as duplicate to that issue.

Please correct me, if I overlook a problem. Please try to write issues, which
describe exactly one problem.



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

I know ooo can 'work' (you mean function?) with more than one languages in a 
document
the 'way I am expect' is the most sensible way (for greek, russian and such 
languages, as its already stated in issue 1035)

you didnt understand something very essential: its not about writing each 
paragraph with different language, its about writing WORDS in the same 
sentence, in different language
so obviouly, we have to mark each word seperately and format it into the 
correct language (its so inconvenient ofcourse)
ooo should do that automatically, by identifying the keyboard layout we use to 
write (when I use greek keyboard layout, I ofcourse write greek text, ooo 
should assume this)

issue 66798 is irrelevant
and yes, issue 1035 describes exactly what I am saying, from 2001 to 2006 how 
come nothing happened for this issue...

I really don't like dragging the name of a competitor into this discussion, but
this is exactly how I do this in Word.  You highlight the word (or words) you
want to be in a different language and then change them.  You cannot change the
keyboard 'on the fly' without changing the language for the entire document
(that is as of Office 2000.)  This is the procedure outlined in Issue 1035 and
that is the 'fix' for this problem.  I feel that this is a limitation of the
Operating System and not a limitation of OpenOffice.org

James M.

OS cant limit ooo or any other application either to recognize the current 
keyboard layout that is used, or to choose what format ooo will use for a text 
that is being typed

its really so OBVIOUS: 

"greek characters in a word mean this word is written in greek, so it has to be 
formated as greek text"

its so basic function, so essential

using greek characters (greek keyboard layout), you CANT write anything BUT 
greek

the issue is that this truth 'keyboard layout must determine the format of the 
text' doesnt apply in languages as german, french etc, because you can write 
english text using a german or french keyboard layout

so developers dont bother

but for all of us that we use languages as greek, russian etc, the above truth 
is absolute

at least they have to make it for those languages

closing duplicate.

duplicate of which?

of 1035 which is unjustified 'closed' and 'fixed' ?

duplicate of which?

of 1035 which is unjustified 'closed' and 'fixed' ?

Reassigned to SBA.

A pragmatic comment:

When the locale of the keyboard is changed, does the OS notify the program (in
this case OOo Writer) that the locale has been changed?

If that is the case, implementing this issue should be easy.

If not, then how does the input at low-level function? (Is here somebody around
who knows this in more detail?) Does the OS send a stream of unicode chars to
OOo? We could test the unicode chars to see which locale they belong. However,
testing this for every word would degrade sligthly performance, on modern
computers I doubt however that there would be any difference.

With both approaches, we could detect both very different languages as greek and
slavik ones (russian), but also emglish, german and many more.

Just my thaughts.

I was thinking more seriosly on this issue and I came with an idea:

The best solution would be if the OS notifies OOo that the keyboard layout has
changed.

HOWEVER: if the OS does NOT do something like this, there could be a solution
for some common situations:
 - when the spellchecking is activated: it checks whenever a word is written, so
  -- implement a routine that checks if the word is written in:
    * cyrillic
    * greek
    * japanese (katakana/ hiragana)
    * chinese/ japanese (kanji)
    * latin (there are some special characters in french, romanian, spanish,
other latin languages, german, other languages, but NOT all words have such a
character -> therefore differentiating between these languages is more
difficult, BUT see also the next point on "Language Lists")
    * (maybe some other locales)
  -- "Language List": let the user specify at the beginning what languages will
be used in the document: e.g. russian, greek and french
    * that way every word written in cyrillic is russian
    * and every word written in latin is french
    * and there is NO need for complex algorithns to search what language the
word belongs, like russian, serbian,... or french, spanish, romanian, ...

IF the automatic spellchecking is not activated, the issue gets more
complicated. [I still do not have a real solution for this.]

theusers,
I have reopened 1035 and closing this one as duplicate of 1035. I fully agree 
with you that the issue is quite important. Please consider voting for 1035.

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

SBA: Closed.

I got an email notification that this issue is solved

is it really solved? do I miss something?

I'm confused. The issue was reported as duplicate (and it is so). The issue
activity also shows this but the status is "unconfirmed". I repeat setting it to
duplicate.

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

closing