https://bugs.documentfoundation.org/show_bug.cgi?id=145853
--- Comment #4 from Eike Rathke <[email protected]> --- (In reply to Yaroslav Serhieiev from comment #2) > and indeed I can see my non-standard BCP47 code at the top of the languages > list, i.e.: "✓ {{sla-Latn-x-isv}}". That looks wrong, it should be "✓ {sla-Latn-x-isv}" (note the single {} braces). May it be you defined literally {sla-Latn-x-isv} in your extension's dictionaries.xcu? It should only be the BCP 47 tag sla-Latn-x-isv without braces. > Honestly, with my code, "sla-Latn-x-isv" I was hoping to see it rendered in > a list as "Slavic languages (Latin) {x-isv}". Starting with LibreOffice 7.3 we rely on the ICU library to provide names for language tags that aren't defined internally by LO. Unfortunately the 'sla' tag seems not to have a proper name there either and 'sla-Latn' is displayed as "sla (Latin) {sla-Latn}" > Presumably, to satisfy this behavior, there should be two conditions met: > 1) LibreOffice source code should have a mapping to interpret "sla" → > "Slavic languages" (and sla-Latn → Slavic languages (Latin), respectively) We will certainly not add yet another table of language subtags to names mappings for hundreds of languages and tags including translations (the IANA language tags registry currently has 9079 entries..). ICU (International Components for Unicode) provides that with its CLDR (Common Locale Data Repository), and if a subtag name is missing then the best place to add it is there. See https://icu.unicode.org/ and https://cldr.unicode.org/ > 2) The language picker rendering (populating) logic should be extended to > handle private BCP47 code extensions (x-...) in the described way: > [interpret primary code] [(interpret script if there is one)] [{print the > remaining x-extension}]. Seeing that and having tried to enter 'sla-Latn-x-isv' it indeed refuses to accept that with its private-use subtag. I would even say with a good reason, because such are not meant to pollute the document space, but I'm not sure however if that's actually the case there or if there's another reason. > If that makes sense to the contributors as well, I could create another > issue for (2) and see if I can find anyone who can help to resolve this. I'll investigate, for now we can just keep this bug here. -- You are receiving this mail because: You are the assignee for the bug.
