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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice