diff options
author | Eike Rathke <erack@redhat.com> | 2023-01-05 18:12:59 +0100 |
---|---|---|
committer | Eike Rathke <erack@redhat.com> | 2023-01-06 14:12:04 +0000 |
commit | b959a2290f218dcae081d30e9da11c5a602ba5a5 (patch) | |
tree | 5eaef807d7c2d9898af906baca2705eea503db5d /vcl/inc/osx/salframeview.h | |
parent | Related: tdf#152781 Add also non-on-the-fly IDs to language list (diff) | |
download | core-b959a2290f218dcae081d30e9da11c5a602ba5a5.tar.gz core-b959a2290f218dcae081d30e9da11c5a602ba5a5.zip |
Related: tdf#152781 Stab the 0xE40A {es} vs Latin America quirk
First, the LANGUAGE_SPANISH_LATIN_AMERICA 0xE40A is not a MS
system LCID, it is Spanish 0x00a with sublanguage 0x39 => user
defined (in the range 0x20 to 0x3f). Meanwhile MS reserved 0x580A
for {es-419}, so obsolete the legacy 0xE40A definition and replace
with 0x580A when encountered.
Second, due to the legacy plain {es} mapping being present, an
encountered 'es' (from our bundled dictionary extension) got
mapped to 0xE40A instead of 0xA and thus was added to the
character language listbox (that otherwise suppresses LCIDs
without sublanguage), resulting in a "Spanish {es}" entry.
Besides, it's currently not clear how to actually proceed with
such dictionary situation when, for example, both 'es-ES' and 'es'
dictionaries are present and the 'es' dictionary apparently is
meant as base and contains entries the 'es-ES' does not or 'es-ES'
overrides entries. It might be it's handled half-way in
linguistics, but maybe not even that, I didn't investigate.
Change-Id: Id859731ba5efa65d4a6de429b7f52027aa69327c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145093
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit 375630ae76f46c096421dfadee8d37b406bc10c5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145114
Diffstat (limited to 'vcl/inc/osx/salframeview.h')
0 files changed, 0 insertions, 0 deletions