On Fri, 2017-07-14 at 15:57 +0200, Eike Rathke wrote:
Questions:
* where does the new implementation live that determines the actual
"resource" to be used for the current UI language, including
possible language fallbacks?
We pass GetUILanguageTag to boost, and that's always one of the
languages we translate to, as opposed to GetLanguageTag which could be
basically anything. So if someone's desktop locale is, say "de_AT",
then boost is just going to get "de_DE" from LibreOffice as the UI
language. boost itself in boost/libs/locale/src/shared/message.cpp (or
somewhere like that) will then try de_DE/module.mo and fallback to
de/module.mo
* does std::locale that replaces ResMgr and Translate::Create() that
uses boost::locale::generator with the new
LanguageTag::getGlibcLocaleString() fully handle BCP47?
No, boost::gettext takes a posix locale string as its argument when it
builds a std::locale to use as input to the translate methods http://ww
w.boost.org/doc/libs/1_48_0/libs/locale/doc/html/rationale.html#why_pos
ix_names which is a bit sucky, but I updated liblangtag to handle the
only one of the locales we translate to (ca-valencia) which it didn't
already know how to map to a posix/glibc locale, so we should have a
valid posix/glibc locale string for each of the bcp-47 language tags
that identify a UI translation target
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.