Bug 83561 - Language variants should function when variant files are not there
Summary: Language variants should function when variant files are not there
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Linguistic (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Spell-Checking AutoCorrect-Complete UX
  Show dependency tree / graph
 
Reported: 2014-09-06 13:47 UTC by Yousuf Philips (jay) (retired)
Modified: 2023-07-09 17:11 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 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 Yousuf Philips (jay) (retired) 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
Comment 5 QA Administrators 2016-09-20 10:12:10 UTC Comment hidden (noise)
Comment 6 Tiago Santos 2016-10-03 15:18:52 UTC 
This is still relevant today. 

Portuguese variants still lack this mechanism.

- Angola Portuguese (pt-AN) and Mozambique (pt-MZ) Portuguese are closer to European Portuguese and they lack all writing aids.
- European Portuguese (pt-PT) lacks the bundled Lightproof grammar checker available for Brazilian Portuguese. Though there are slight grammar differences, having it linked would be appreciated.
- Brazilian Portuguese (pt-BR) lacks a bundled thesaurus, that exists on the European Portuguese version.
Comment 7 QA Administrators 2017-10-23 14:06:29 UTC Comment hidden (noise)
Comment 8 Dr Anirban Mitra 2019-08-04 08:23:02 UTC 
This bug is untouched yet. I am using Version: 6.0.7.3 in Ubuntu 18.04 yet I can not do spell check if I set language to English India I can not do spell correction or set language from spelling dialog box.
Comment 9 Julien Nabet 2019-08-04 09:28:59 UTC 
(In reply to Dr Anirban Mitra from comment #8)
> This bug is untouched yet. I am using Version: 6.0.7.3 in Ubuntu 18.04 yet I
> can not do spell check if I set language to English India I can not do spell
> correction or set language from spelling dialog box.

6.0 and 6.1 are EOL.
Please give a try to a recent LO version. (last one is 6.2.5).
You can find it on LO ppa (see https://launchpad.net/~libreoffice/+archive/ubuntu/ppa)
Comment 10 QA Administrators 2022-09-22 03:55:25 UTC Comment hidden (noise, obsolete)
Comment 11 Stéphane Guillou (stragu) 2022-12-12 15:59:16 UTC 
In my opinion, it should be each Native Language Community's decision to pick a fallback dictionary for their language, case-by-case, instead of using blanket solutions for them and risking inappropriate decisions (especially when an area's language history is tied with colonialism).

I assume that we don't have that fallback mechanism implemented just yet, and that technical aspect could be the focus of this report.

Once it has been implemented, we could have NLCs decide for themselves what sensible fallback should be used for their language (if any), until a proper dictionary (and grammar checker, and autocorrect list) is used.

Sophie, what's your opinion?
Comment 12 sophie 2022-12-12 16:12:50 UTC 
(In reply to Stéphane Guillou (stragu) from comment #11)
> In my opinion, it should be each Native Language Community's decision to
> pick a fallback dictionary for their language, case-by-case, instead of
> using blanket solutions for them and risking inappropriate decisions
> (especially when an area's language history is tied with colonialism).
> 
> I assume that we don't have that fallback mechanism implemented just yet,
> and that technical aspect could be the focus of this report.
> 
> Once it has been implemented, we could have NLCs decide for themselves what
> sensible fallback should be used for their language (if any), until a proper
> dictionary (and grammar checker, and autocorrect list) is used.
> 
> Sophie, what's your opinion?

Yes agreed, asking l10n teams what is their needs once the fallback is implemented would be the best approach.
Comment 13 Stéphane Guillou (stragu) 2023-04-06 06:14:19 UTC Comment hidden (obsolete)
Comment 14 spspinz 2023-04-14 00:54:56 UTC Comment hidden (obsolete)