1. open a modul e.g. writer
2. set the language to another language except en
3. type any correct text
4. copy it
5. open another modul e.g. calc
6. paste the text.
now you have nor correct spellchecking, the language-id for the cell is set to en-US, nor posibility to change it, the language seen in tools -> spelling and grammar can't be modified.
This is an old bug from OOo, (issue 48509 , year 2005 !!!!!!)
More or less [Reproducible] with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]"
I proceeded as reported (details see in "textsource.odt" from attached testkit) and see that the former correct language of Calc Cell "German" changes to "none" when Copy/Paste.
I can not reproduce that cell text language is set to English (but to "none", selector is empty). But when I close and reopen document language selector shows "English-US".
I do not understand reporter's "... the language seen in tools -> spelling and
grammar can't be modified".
I can not reproduce that the Cell text langguage can not be modified, 12. 'Format -> Cells -> Font' works fine.
Strange thing, the problem does not appear when I Copy/Paste a Spanish text line, Please see "Spanish_textsource.odt" / "Spanish_pastedtext.ods"
The good Spanish result also is reproducible with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: d3d1481-3f8994a-2ba0a9f)]".
Worked fine with OOo 3.1.1 German UI
I will test LibO 3.3.3 later
Please help me to understand "the language seen in tools -> spelling and
grammar can't be modified"
There is a very vague suspect that this one might be "somehow" related to Bug 39365 .
I saw you active in some Linguistic Component SPELL check bugs. Please feel
free to reassign (or reset Assignee to default) if it’s not your area or if
provided information is not sufficient. Please set Status to ASSIGNED if you
accept this Bug.
Created attachment 50988 [details]
Test kit, see Comment 1
Also [Reproducible] with "LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 126.96.36.199)]".
Looks like OOo heritage.
Ah I see, its undoubtedly because the text in the German one is the same as the document default language and/or the underlying style so its not explicitly overridden for the selection, while it is for the Spanish one. i.e. as far as the cut and paste process is concerned its sort of a "take text with writer's defaults and paste it to calc and take calc's defaults".
e.g. select the text, make it "Default" style in writer, then change default paragraph font properties to e.g. 60pt font and paste into calc, you get the Default paragraph font size of calc not that of the original.
I suppose, really, there's a lot of things wrong, and I'm getting side-tracked by this, so lets pull back a bit. Initial bug report is "language is not copied and pasted", so after the fix of http://cgit.freedesktop.org/libreoffice/core/commit/?id=8cc839dc6ac3239bc4a3738cfb6078a8bf92ea72 the language should be copied and pasted. i.e. "job done"
When we copy and paste here writer was only putting into the temporary paste document the paragraphs to be pasted, with no inclusion of the styles those paragraphs used so the (rtf in this case) exporter couldn't export what the language was because that information wasn't included when the language was the source documents default language.
So defaults and styles are now copied into the temp document, could optimize this by only adding the *used* styles into the temp doc.
The other half of the story is the (old) rtf parser used by the editengine which is the consumer of the rtf is a bit poor with lang/alang/langfe and similar support. But for the provided Western/Latin the right thing happens.
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.