On installing LO 4.2 RC2 for Brazilian Portuguese, the UI has strings intermixed with pt-PT. Steps to reproduce: 1) On a Windows 7 pt-BR, run a typical installation of LO 4.2 RC2 until completion. 2) Open any LO module, watch the UI Some Menus examples en-US pt-BR pt-PT File Arquivo Ficheiro Save Salvar Guardar Delete Excluir Eliminar Note: Since ages, pt-PT UI is installed alongside with pt-BR UI. If I drop pt-PT from the installed languages, the UI is then in fully pt-BR.
@Olivier: Try to switch language to for example en-US, then back to pt-BR. Then you should not see pt-PT strings. At least this is what I experienced with hu. I installed 4.2 rc2 to English Windows 7, locale was Hungarian. LibreOffice started in Hungarian, while the UI language setting displayed English (US). 4.2 beta2 on the same machine started in English as expected. Suspicious commit: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-2&id=57bf54e1691691c606cd04baa60b677b9376c2ae
en-US UI is not available on my pt-BR installation (incidentally en-US was *always available* in the past... perhaps this is another bug) So I switched to pt-PT and back to pt-BR and it fixed the UI. Therefore no need to remove pt-PT from the installed languages set.
4.2.0.1 rc was good - regression
Both reports seem to stem from Windows, was this reproducible on Linux? (would be good if so ;-) @Olivier: Both your system UI and system locale are pt-BR?
@Eike: I started to bisect it on Windows.
(In reply to comment #4) > Both reports seem to stem from Windows, was this reproducible on Linux? > (would be good if so ;-) > > @Olivier: > Both your system UI and system locale are pt-BR? yes, W7 pt-BR in a VM.
03e7a16fe2802160b8344058f225a57bdb9c59f5 is the first bad commit commit 03e7a16fe2802160b8344058f225a57bdb9c59f5 Author: Eike Rathke <erack@redhat.com> Date: Thu Dec 19 12:24:31 2013 +0100 use proper LanguageTag fallback instead of dumb startsWith(), fdo#68714 A ca_ES@valencia (=> ca-ES-valencia) locale did not result in 'ca-valencia' UI being selected but 'ca' only instead. Change-Id: Ifa405add2ff7b45e030b02af4338de195b457cb2 interesting log messages: warn:i18nlangtag:2916:4156:i18nlangtag/source/languagetag/languagetag.cxx:1643: LanguageTag::getRegionFromLangtag: pRegionT==NULL for '${PRODUCTLANGUAGE}' warn:i18nlangtag:2916:4156:i18nlangtag/source/languagetag/languagetag.cxx:1405: LanguageTagImpl::convertLocaleToLang: with bAllowOnTheFlyID invalid '${PRODUCTLANGUAGE}' warn:i18nlangtag:2916:4156:i18nlangtag/source/languagetag/languagetag.cxx:1583: LanguageTag::getLanguageFromLangtag: pLangT==NULL for '${PRODUCTLANGUAGE}'
I wonder what feeds a literal '${PRODUCTLANGUAGE}' as a language tag ... However, taking this for the weird language mix.
(In reply to comment #8) > I wonder what feeds a literal '${PRODUCTLANGUAGE}' as a language tag ... Sorry, I forgot to comment. I found out later. In dev-install there is a file called forcedefault.xcd, that contained ${PRODUCTLANGUAGE}. I didn't understand why we wanted to force UILocale at all. And it should have been replaced to a languagetag at some stage.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e826c7ff7c597e9f585377b2117f4dc24239dcc fdo#73549 do not attempt to resolve an empty locale The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=db6f8f9f8969b592ed90c841960fdd186e1cbc5a fdo#73549 do not resolve empty locale here if not determined yet The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=26fc9be1bf2d6aaeb52a571ea416f4527a52e146 do not resolve empty locale here when set, fdo#73549 related The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review for 4-2 at https://gerrit.libreoffice.org/7529 for 4-2-0 at https://gerrit.libreoffice.org/7530
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cf32bd06da9d215e8a337ad611651664142e8a65&h=libreoffice-4-2 fdo#73549 do not attempt to resolve an empty locale It will be available in LibreOffice 4.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5f209df8858e56e639394687784d34d3944acad5&h=libreoffice-4-2-0 fdo#73549 do not attempt to resolve an empty locale It will be available already in LibreOffice 4.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.