Red Hat Bugzilla – Bug 118509
Word Doc export assumes language DE
Last modified: 2007-04-18 13:04:22 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Galeon/1.3.13 Description of problem: Any export (with any language selected) to a 97/2000/XP Word DOC file will export it as Language DE. I don't know if anyone cares about this, but Word Perfect, on importing these files, sees the tag and starts asking crazy spelling correction questions and marks the entire file as spelled incorrectly. At least, for my US English locales in Linux/OpenOffice and Windows/PerfectOffice Version-Release number of selected component (if applicable): openoffice.org-1.1.0-30 How reproducible: Always Steps to Reproduce: 1. Create document 2. Save 3. Export as 97/2000/XP MS Word Doc 4. Import it into anything where you can see what language it is declared as, it will always be german. (LANG DE) Actual Results: Language is DE in any document Expected Results: Language should be undeclared or should be declared according to the preferences set (US/EN in my case) Additional info:
Any chance you could attach the document, or at least a stripped down document that exhibits this behavior? Also could you do the following and report here? 1) In a terminal window, type "echo $LANG" 2) IN OOo, what are the values in the combo boxes of the Tools->Options->Language Settings->Languages preference page? Thanks....
$ echo $LANG en_US.UTF-8 Language of Locale Setting: default Default currency: default Western Languages for documents western: English (USA) asian/ctl are greyed out the three checkboxes after that are all unchecked. Maybe OOo doesn't understand US.UTF-8 and the default values are screwed up?
wordperfect is borked. There is a document language set in .doc files, and then there is a language property set on the default style, and everything inherits from the default style. So if (as is certainly exported correctly in 1.1.X) the default/normal style is exported with a language "en-US" and the document language is exported as "de-DE" then the text in the document is by default in english and not german, so wordperfect thinking it is in german is plain wrong. What is set as the "document language" doesn't actually matter to the user for documents because if the language is set in the default/normal style then it overrides the document language, and for .doc export/import this always happens. Now why do we export the documents with a language id of "german", this is because for .doc files this language is the language which will be used for the field names, like AUTHOR, PAGE NUM etc in the document. Those must be exported in the language that matches the document language id. The default/normal style can override it, but the names of fields must be in this language. It just so happens that the original developer of the .doc filter in OpenOffice.org was german so he exported document languages of german and german field names. Since word 2000 msoffice itself also always exports documents with a fixed document language id, in their case always english, regardless of the actual language of the default style. i.e. word 2000+ does exactly the same thing as OpenOffice.org 1.1.X, except using english instead of german (theres a MSDN knowledge base article about it which explains that they did it to be consistent in their VBA programming environment where apparently code works on the field names, and language differences were breaking macros). Because of the ms change to a fixed english document language, for OOo 2.0 I also changed the export of .docs to be document language english and use english field names, instead of german doc language and german field names. This is purely a cosmetic change, expect for the obscure issue of macros which work off the field string text. What you are seeing makes me thing that there is a flaw in wordperfect's .doc import, where they might have also have a similiar difficulty with non us-english .doc generated from word 2000+. Its a fair amount of effort to backport the 2.0 change to the 1.1.X series to workaround a wordperfect flaw which I suspect would still affect non us-ascii msword 2000+ created .docs.