Bug 83561

Summary: Language variants should function when variant files are not there
Product: LibreOffice Reporter: Jay Philips <philipz85>
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: NEW --- QA Contact:
Severity: normal    
Priority: high CC: barta, fitojb, nainapardeshi5, serval2412, timar74
Version: Inherited From OOo   
Hardware: Other   
OS: All   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=79276
Whiteboard:
i915 platform: i915 features:

Description Jay Philips 2014-09-06 13:47:05 UTC
Similar to bug 79276, auto correct and spell check should work when a language variant's files are not present but the primary language files are.

A user tweeted < https://twitter.com/raju_thorat/status/507034090088853504 > that he has english-US installed, but as his default language for documents set to english-India, he is unable to use the english spellcheck as there isnt a check mark next to it < https://pbs.twimg.com/media/BwlY0PwCUAIsPMy.png >.

I can confirm this behaviour happens in Linux Mint 17 with 4.3.1 (only USA has check mark) and Ubuntu 14.04 with 4.2.5 (only AU, CA, SA, UK, and USA have check marks).
Comment 1 Julien Nabet 2014-09-06 17:17:59 UTC
Jay: I'll let you edit the title of the bugtracker since something's lacking :) 

Andras: I thought about doing about the same as this:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4f411ba62d4fd7fd4a61d1c9d326488d5e84ff5
but in the case of English, I'd rename en-US/acor_en-US to en/acor_en since English US would be the default.
More generally, should we follow a general rule that would be one "generic variant" for each language?
Eg: ja-JP/acor_ja-JP.dat would be renamed to ja/acor_ja
(Still, there would be some cases to decide like:
- acor_zh-CN
- acor_zh-TW 
)

Any idea?
Comment 2 Jay Philips 2014-09-06 18:47:10 UTC
(In reply to comment #1)
> Jay: I'll let you edit the title of the bugtracker since something's lacking
> :) 

:D

> Andras: I thought about doing about the same as this:
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=a4f411ba62d4fd7fd4a61d1c9d326488d5e84ff5
> but in the case of English, I'd rename en-US/acor_en-US to en/acor_en since
> English US would be the default.

Please dont forget dictionaries files as well, as that was the main reason of the bug. :)

/share/extensions/dict-en/
Comment 3 Julien Nabet 2014-09-06 19:18:32 UTC
Argh! Again I confused autocorrect and dictionaries :-(
Forget my last comments then :-(
Comment 4 tommy27 2014-09-28 06:45:34 UTC
(In reply to comment #1)
> Jay: I'll let you edit the title of the bugtracker since something's lacking
> :) 
> 
> Andras: I thought about doing about the same as this:
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=a4f411ba62d4fd7fd4a61d1c9d326488d5e84ff5
> but in the case of English, I'd rename en-US/acor_en-US to en/acor_en since
> English US would be the default.

currently default autocorrect english datasets include:
en-AU (Australia)
en-US (United States)
en-GB (Great Britain)
en-ZA (South Africa)

other English variants that do not have a specific autocorrect set are:

Belize, 
Canada, 
Caribbean, 
Ghana, 
India,
Ireland, 
Jamaica, 
Malawi, 
Namibia, 
New Zealand, 
Philippines, 
Trinidad, 
Zimbabwe

as far as I know, most of those variants belong to Commonwealth countries so they derive from English GB root languages rather than English US.

so my suggestion would be to clone the "acor_en-GB.dat" file and rename it to "acor_en.dat" and use that generic .dat file to pupulate the other languages.

in other words we should have:
en-AU (Australia)
en-US (United States)
en-GB (Great Britain)
en-ZA (South Africa)
en    (Generic clone of en-GB)

then if in second phase we found that some countries would have a better match with en-US, we could clone this as well and rename it to the proper locale.

for example if you think English (Canada) is more similar to en-US rather than en-UK we should clone en-US and rename it as en-CA

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.