Problem description: Having a list of Arabic ($country) is redundant. Unlike en_US and en_GB, the spell checking of the Arabic language doesn't depend on the country. Steps to reproduce: 1. Tools - Options - Language Settings - Languages Current behavior: There is a list of: Arabic (Algeria), Arabic (Egypt), Arabic (Lebanon), Arabic (Oman), Arabic (Saudi Arabia), Arabic (Tunisia) Expected behavior: To have only one option: Arabic Operating System: Linux (Other) Version: 4.0.3.3 release
AFAIK, the spell dictionaries was duplicated per country because OpenOffice didn’t look for “ab” dictionary if it didn’t find “ab_CD” one. So we need to check is this still the case and fix that (but I’m might be tricky, IIRC for some locales such behaviour would be undesired). There is probably a bug for this somewhere in the OpenOffice issue tracker.
Eike, any pointers about the linked OOo issue, any chance that your language tags work help here?
I thought, naïvely, that may be I can try to use MsLangId::getPrimaryLanguage() as fallback. First, SpellChecker::hasLocale() in lingucomponent/source/spellcheck/spell/sspellimp.cxx is never called (not by Writer at least), so whatever I do there does not matter. What gets called, however, is SpellCheckerDispatcher::hasLocale() in linguistic/source/spelldsp.cxx (which took me a while to find going through all that convoluted UNO stuff), but passing the primary language to aSvcMap.find() there does not find anything, apparently the spell checker for "ar" is never registered or something, but I gave up at this point since the code on that file is too clever for me to grasp.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Still an issue.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still an issue
This same issue affects many other languages for which putting their dictionaries into the ‘locale’ mold creates extra work, for example, French and Dutch, both languages that are mostly ‘standardized’ worldwide qua spelling. So perhaps make the bug title broader.
Code pointers from the mailing list https://lists.freedesktop.org/archives/libreoffice/2017-February/076982.html (mainly so that I do not forget where to find them).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #10) > If the bug is present, please leave a comment that includes the information > from Help - About LibreOffice. Still present in 6.0.6.2.
Dear Munzir Taha, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #12) > If the bug is present, please leave a comment that includes the information > from Help - About LibreOffice. Still present in 6.2.5.2.
Still present in 6.4.7.2 This bug really complicates how downstreams (such as Linux distributions) need to deal with spelling/thesaurus/hyphenation files. Also, again a request to change the title of this bug to something that better covers the issue. For example, “Accept spellcheck files without region”. Furthermore, I guess LO should just try to respect bcp47 <https://tools.ietf.org/html/bcp47>, <https://en.wikipedia.org/wiki/IETF_language_tag>
@Erik: It's correct that "Accept spellcheck files without region" is part of my issue as Mr. Khaled pointed out. But I am hesitant to change the title because after the fallback mechanism we also need to remove the duplicates. Unlike English which you might want to keep en_US, en_GB and fallback to en, we shouldn't keep any regions files for Arabic spellchecking.
(In reply to Munzir Taha from comment #15) > @Erik: > It's correct that "Accept spellcheck files without region" is part of my > issue as Mr. Khaled pointed out. But I am hesitant to change the title > because after the fallback mechanism we also need to remove the duplicates. > Unlike English which you might want to keep en_US, en_GB and fallback to en, > we shouldn't keep any regions files for Arabic spellchecking. As Khaled Hosny indicated in Comment 1, the only reason there are country variants for Arabic now is because LibreOffice isn't able to deal with codes without a country designation. The same holds for Dutch (and I guess French). However, if someone wants to create a separate regional variant spellcheck bundle, e.g., nl_BE for Dutch in Belgium (even if Dutch is standardized for all countries where Dutch is spoken), such would still need to be accepted by LibreOffice, as we shouldn't impose restrictions. In any case, I think it is up to the developers to make the call whether to change the title or not.
No need to rename this bug report, the more generic bug 83561 already exists. Added in "See also".
So, having gone through the comments, there's something I don't understand. Why does the locale even define the choice of spellchecking dictionaries, at all? First, and in principle - all dictionaries should be active/in-use, with the language/language-variant of a stretch of text deciding which dictionaries apply to which part of the text. See also bug 148257. And in this idealized world, if some text is in, say, Arabic (Iraq), then it would get both the general Arabic spell-checking dictionary used for it, and the specific Iraqi dictionary. On the other hand, once you support multi-level dictionaries, you also need to support "anti-entries", i.e. a word might be valid in Arabic generally but a local variant would forbid it. I'm guessing we don't have that? Anyway, continuing with my ideal-world example: The user would want/need the ability to tweak the defaults. That would mean a list with checkboxes, and a drop-down list box above it for choosing which language / language-variant you want to tweak dictionary choice for. There you could decide you want to disable or enable some dictionaries (and there are also special dictionaries like "technical" which may be relevant to multiple languages). And in all of the above, the choice of Locale and of UI language have absolutely no bearing on anything.
I’m repurposing this issue for fixing the need to duplicate hunspell Arabic dictionaries. For other languages, please open bug reports with specific details. The fact that many languages require having many sub locales is not something we can easily change. In some situations the country code is irrelevant (e.g. spell checking in the case of Arabic) and in some situations it is relevant (currency, number formatting, etc). We have only one kind of language setting, that is used for spell checking, hyphenation, and many other situations, so we can’t simply merge all locales of a given language together because it will fix some issues but break others. There is also compatibility issue with formats that don’t offer country-less locales. There is no general way to handle this (what works for a specific locale does not necessarily work for others), so it needs to be spec’d in full detail before any code is written.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2940fb7d2aba063441e7ce70bb276bfe912ed73e tdf#64830: Don’t require hunspell dictionary for every Arabic locale It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks so much Dr. Khalid for the fix. Please, note that according to https://unicode.org/cldr/charts/44/summary/ar.html you might have missed ar-SS. Though I am not sure what qualifies a country to have an Arabic locale when the Arabic language is not an official one, but I just don't want it to show on the list.
(In reply to Munzir Taha from comment #21) > Thanks so much Dr. Khalid for the fix. Please, note that according to > https://unicode.org/cldr/charts/44/summary/ar.html > you might have missed ar-SS. > > Though I am not sure what qualifies a country to have an Arabic locale when > the Arabic language is not an official one, but I just don't want it to show > on the list. Thanks, we don’t seem to have any support for this locale, but I’ll added it just in case. Also note that this “fix” does not hide any of the Arabic locales, it just makes it unnessary to have ar-SA.dic, ar-EG.dic etc. hunspell dictionaries, if ar.dic is present it will be used for all the listed Arabic locales. It is strictly a bug fix. Hiding the Arabic locales in some contexts at least, or being able to set the language to Arabic without a country code is a bigger issue that needs deeper changes and have compatibility considerations, so please open a new issue to track this if it is nit covered by one of the issues in the See Also field.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/376aded127cd5c9030c3b52fd2095c4241abc053 tdf#64830: Don’t require hunspell dictionary for every Arabic locale It will be available in 7.5.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
خالد حسني committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/e3c88bfcd1b22dd7eef367c688f004cea0d5222e Revert "tdf#64830: Don’t require hunspell dictionary for every Arabic locale" It will be available in 7.5.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.