Bug 73549 - pt-BR UI strings intermixed with pt-PT after typical installation
Summary: pt-BR UI strings intermixed with pt-PT after typical installation
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
4.2.0.2 rc
Hardware: Other Windows (All)
: medium normal
Assignee: Eike Rathke
QA Contact:
URL:
Whiteboard: target:4.3.0 target:4.2.0
Keywords: regression
Depends on:
Blocks:
 
Reported: 2014-01-13 11:09 UTC by Olivier Hallot
Modified: 2014-01-20 14:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2014-01-13 11:09:20 UTC
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.
Comment 1 Andras Timar 2014-01-13 11:38:34 UTC
@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
Comment 2 Olivier Hallot 2014-01-13 11:50:28 UTC
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.
Comment 3 Andras Timar 2014-01-13 12:16:05 UTC
4.2.0.1 rc was good - regression
Comment 4 Eike Rathke 2014-01-13 13:09:03 UTC
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?
Comment 5 Andras Timar 2014-01-13 13:19:28 UTC
@Eike: I started to bisect it on Windows.
Comment 6 Olivier Hallot 2014-01-13 16:48:10 UTC
(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.
Comment 7 Andras Timar 2014-01-14 08:19:33 UTC
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}'
Comment 8 Eike Rathke 2014-01-16 16:21:45 UTC
I wonder what feeds a literal '${PRODUCTLANGUAGE}' as a language tag ...

However, taking this for the weird language mix.
Comment 9 Andras Timar 2014-01-16 16:29:10 UTC
(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.
Comment 10 Commit Notification 2014-01-17 22:51:12 UTC
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.
Comment 11 Commit Notification 2014-01-19 14:04:40 UTC
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.
Comment 12 Commit Notification 2014-01-19 14:04:55 UTC
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.
Comment 13 Eike Rathke 2014-01-19 14:21:24 UTC
Pending review
for 4-2 at https://gerrit.libreoffice.org/7529
for 4-2-0 at https://gerrit.libreoffice.org/7530
Comment 14 Commit Notification 2014-01-19 14:24:49 UTC
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.
Comment 15 Commit Notification 2014-01-20 14:50:12 UTC
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.