https://bugs.documentfoundation.org/show_bug.cgi?id=161744
Eike Rathke <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|7.6.7.2 release |unspecified CC| |[email protected] --- Comment #15 from Eike Rathke <[email protected]> --- (In reply to V Stuart Foote from comment #13) > (In reply to Heiko Tietze from comment #5) > > Or, to keep the list more clean, add an option below "[ ] Localize". > > Regards doing a "[ ] Localize"--wouldn't the CLDR details be found in the > LC_COLLATION and LC_INDEX record? No. Collation is sorting/ordering and may follow the standard Unicode collation order (in fact our mn-Cyrl-MN locale data simply refers <LC_COLLATION ref="en_US"/>), while alphabetic numbering may be defined differently. LC_INDEX is close, but may differ from numbering and also is not sufficient, as we need a persistent unique identifier to store the numbering in ODF, that does not change if data for some reason changes. That can be auto-generated for distinct numbering sequences using their first three letters, but (not only) for Cyrillic is locale dependant if the first three letters are equal among some locales but other letters are not. See for example the Bulgarian, Russian, Serbian, Ukrainian cases in https://opengrok.libreoffice.org/xref/core/i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx?r=be1c9ee5#156 and their identifiers in the table at https://opengrok.libreoffice.org/xref/core/i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx?r=be1c9ee5#1132 that DefaultNumberingProvider::makeNumberingIdentifier() https://opengrok.libreoffice.org/xref/core/i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx?r=be1c9ee5#1160 uses. > the > locale/lang codes are odd reusing generic 'qlt' "a locale language" for many > in addition to the country codes. That is a convention needed for the UNO API to be able to still transport a full BCP 47 language tag in the fixed inflexible Java Locale struct that has only Language, Country and Variant fields, where Language an Country can only hold the ISO codes. If a language tag does not consist of purely language and country alphabetic ISO codes, then we use the 'qlt' "Reserved for local use" language code (mnemonic Q Language Tag) and the actual language tag is in the Variant field, Country may be filled if it fits. Here for Mongolian Cyrillic it's Language = "qlt" Country = "MN" Variant = "mn-Cyrl-MN" The 'qlt' never faces document storage. > Meaning we can currently automate? What do you mean? > Think Eike is going to need to comment/participate here on how/if this could > be automated and what would need be done in our i18n CLDR data stores. Please do not confuse Unicode CLDR and our LO locale data. Initially OOo contributed its locale data to CLDR and now we may align our data if CLDR changes are desired, but don't do it for every case. -- You are receiving this mail because: You are the assignee for the bug.
