Extension installed but language not found in the list

[sinaahmadi]

Hi,

I am trying to create an extension for the freshly-created spell-checker of Kurmanji Kurdish. Even though the structure of the project is identical to that of Sorani Kurdish, the name of the language is not among the list of the languages when I install the extension.

To further clarify, I use "kmr-Latn" as the language code. Do you think the fact that there is already a kmr_Latn code available would create a conflict with the one that I try to install?

Whan can explain an extension being added successfully but not shown in the list of languages.

Thanks for your help in advance.

[dennisroczek]

@erAck I guess you can help here. :-)

[erAck]

If it still interests.. (apart from that issues are not a help board, this is 17 months old..).

To further clarify, I use "kmr-Latn" as the language code. Do you think the fact that there is already a kmr_Latn code available would create a conflict with the one that I try to install?

Yes of course it would, why would you think otherwise? Apart from that the ckb dictionary you linked to does not contain the kmr-Latn tag. kmr-Latn or kmr-Latn-TR (mapping to the default locale) is displayed as "Kurdish, Northern (Turkey)" in the language list. There is also kmr-Latn-SY displayed as "Kurdish, Northern (Syria)" predefined. If you want another tag and display name I could suggest kmr-Latn-IQ (if you wanted to express Northern Kurdish in the Kurdistan Region) that in a recent LibreOffice release automatically displays as "Kurdish (Latin, Iraq) {kmr-Latn-IQ}". Or come up with a distinct different and valid language tag.

See
https://www.w3.org/International/questions/qa-choosing-language-tags
https://r12a.github.io/app-subtags/
and if interested in overwhelming information https://erack.de/bookmarks/D.html#Language_Tags

[sinaahmadi]

Thanks for raising this issue again.
I found a workaround to install the spell-checker as an external plugin from the local file. But I still want to know how I can make the spell checkers available on the official release of LibreOffice. Any hints?

The project is available for both Sorani (ckb) and Kurmanji (kmr) at https://github.com/sinaahmadi/KurdishHunspell/

Thanks.

[erAck]

The best, once you have the proper non-clashing language tag for the dictionaries.xcu's Locales element, is to publish the extension you have already at https://extensions.libreoffice.org/

However, if it is meant to replace or complement the existing ckb and/or kmr-Latn dictionaries and be bundled with the localized LibreOffice releases then get in contact with the project, i.e. the l10n mailing list, see https://www.libreoffice.org/community/localization/

[sinaahmadi]

Thanks for the advice. I did get in touch with the l10n mailing list a couple of years ago. The procedure is not very clear and at some point, I felt that everyone wanted to drop the issue like a hot potato! The same is true for Mozilla. It's just impossible to find someone who cares about the issue.

[dennisroczek]

Thanks for the advice. I did get in touch with the l10n mailing list a couple of years ago.

The ml from TDF? I didn't found the post. 😞

The procedure is not very clear and at some point, I felt that everyone wanted to drop the issue like a hot potato!

Did you read https://wiki.documentfoundation.org/Development/Dictionaries ? It redirects multiple times to the dev mailing list...

[varunkasnia]

I can now confirm this with UI-level evidence.

LibreOffice already defines the following locales internally:

• kmr-Latn-SY → “Kurdish, Northern (Syria)”
• kmr-Latn-TR → “Kurdish, Northern (Turkey)”

These predefined entries are visible in the language selector
(Tools → Language → For Selection → More…), as shown in my screenshot.

Because Hunspell extensions derive the locale from the .aff/.dic filenames,
using kmr_Latn.* causes LibreOffice to map the dictionary to an existing
predefined locale instead of registering a new language entry. As a result,
the extension installs successfully but does not appear as a distinct language.

This explains the observed behavior and confirms that the issue is a locale
tag collision, not a problem with the Hunspell dictionary itself.
Using a non-clashing valid BCP-47 tag (e.g. kmr-Latn-IQ) is required if a
separate language entry is intended.