Bug 109427 - Path to en/svx.mo not found when accessing the (font) color picker in the toolbar
Summary: Path to en/svx.mo not found when accessing the (font) color picker in the too...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All Windows (All)
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0
Keywords:
Depends on:
Blocks: Too-Much-File-Access
  Show dependency treegraph
 
Reported: 2017-07-27 09:18 UTC by Telesto
Modified: 2017-07-31 15:47 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 Telesto 2017-07-27 09:18:21 UTC
Description:
Not sure if it's worth mentioning, but svx.mo can't be found accessing the color picker in the toolbar. Process Monitor reports: Path not found for:
C:\Program Files (x86)\LibreOfficeDev 6\program\resource\en\LC_MESSAGES\svx.mo
C:\Program Files (x86)\LibreOfficeDev 6\program\resource\en_US\LC_MESSAGES\svx.mo


Steps to Reproduce:
1. Open Writer
2. Open Process Monitor with filter set to Process Name is soffice.bin
3. Open the 'drop down' menu for the font color picker 

Actual Results:  
LibO fails finding svx.mo at:
C:\Program Files (x86)\LibreOfficeDev 6\program\resource\en\LC_MESSAGES\svx.mo
C:\Program Files (x86)\LibreOfficeDev 6\program\resource\en_US\LC_MESSAGES\svx.mo

Expected Results:
Not sure if this is normal or not


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 6.0.0.0.alpha0+
Build ID: 781a30e938c58c4d91d08f8c6f9e3f8745682d72
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-27_04:41:54
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Gabor Kelemen (allotropia) 2017-07-28 12:15:34 UTC
I think LO should not look for *US* English translation ever - we don't even have one.

Also: is this happening for other .mo files too or only this one?

CC Caolán: any idea why is this happening?
Comment 2 Caolán McNamara 2017-07-28 12:59:41 UTC
This is normal and not a bug. FWIW the matching code for those accesses is Translate::Create(sType.getStr(), Application::GetSettings().GetUILanguageTag()) in vcl/source/window/builder.cxx in the "domain" handling tag, so this happens for all things loaded from .ui files. Its expected that there will be no .mo for the English US case.
Comment 3 Commit Notification 2017-07-31 15:47:38 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6ea9062d233e153a5df0e7368af4c6a49d955485

Related: tdf#109427 cache std::locales

It will be available in 6.0.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.