Description: I have a template that I've used for my professional resume. After sending it out, I realized there was a minor misspelling that LibreOffice did not catch. I brought the template back in and created more misspellings, and they are not noticed by the code. Steps to Reproduce: 1. Bring in this template to LibreOffice 2. In the bulleted section, misspell anything 3. Note that the spell check does not detect same Actual Results: Misspelled words are not detected. Common words that any spell check would recognize. Auto-spellcheck is enabled, manual spell check was used as well, both failed. Expected Results: Expected that any misspellings would be detected. I have the template here that I can send to someone for analysis upon request. There is no method to attach it here. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Mac OS X (All) OS is 64bit: no
(In reply to Forrest Aldrich from comment #0) > > I have the template here that I can send to someone for analysis upon > request. There is no method to attach it here. There is a method - please use "Add an attachment".
Created attachment 174761 [details] This is the sample template that I used. This is the sample template that I used.
Principle: Spell checking appears based on the language settings of text portions - This document is not a template in the sense of LibreOffice template (.ott) but an exemplar of a CV - The document seems to have a history with Google Docs since its language settings is {en} (which is typical for Google Docs exported to .ots format) instead if "English (USA)" (or any other language variant of English, which is supported by LibreOffice). In consequence there is no spell checking, since {en} is not a supported language of LibreOffice See also: bug report tdf#137742 Solution: - Open the document - In "Tools -> Options -> Language Settings -> Language" replace Western Language (which is now {en}) by "English (USA)" (or any other variant of English, which applies to your situation) - Click button "Apply" - Check wavy red lines appearing in sample document From my perspective not a bug, but an unsupported language setting of the document (version 7.3 should contain a fix for this)
(In reply to Uwe Auer from comment #3) > > - The document seems to have a history with Google Docs since its language > settings is {en} (which is typical for Google Docs exported to .ots format) Typo correction: (which is typical for Google Docs exported to .odt format)
Understood, I did not realize; thank you for looking into this.
This is fixed, and was a duplicate *** This bug has been marked as a duplicate of bug 137742 ***
This is not exactly a duplicate of bug 137742 and wasn't fixed with it; that one implemented a workaround for OOXML documents only, not touching the ODF case here. I'm reopening this bug for the records of known problems, but I also refuse to implement the same sledgehammer workaround mechanism because a language-only attribution is *valid* in ODF context *iff* intended correctly. Google Docs just generates broken documents here. It seems only Google Docs text documents are affected, but not spreadsheets. A "solution" would have to take the document type and <meta:generator> value into account and "fix" things only for specific known bad generators. In this case the generator is "LibreOfficeDev/6.0.5.2$Linux_X86_64", a self-built version Google uses apparently to feed it via API and let it write ODF documents. If needed, even an external preprocessor could fix things changing <style:...-properties> elements' fo:language="en" fo:country="none" attributes to fo:language="en" fo:country="US" or whatever language-region / locale is desired. In any case, whoever is affected should report the problem to Google.