Project

General

Profile

Actions

Emulator Issues #6883

closed

Locales not being loaded from /usr/local/share/locale with wx3.0

Added by tomman about 11 years ago.

Status:
Won't fix
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What's the problem? Describe what went wrong in few words.
I was building Dolphin with a local install of wx2.9 (which I had to build from scratch as I'm on Debian and such version wasn't in the repos), and locales used to work fine there.

Recently, wxWidgets finally released wx3.0, and we finally got modern wx on Debian (they weren't unwilling to package 2.9 as it was a development branch), so I got rid of my local wx2.9 install and just installed wx3.0 from the Testing repos. Dolphin builds and runs just fine with such version, except for a little detail: locales now don't work anymore! Since my locale is Spanish (es_VE), the UI still loads with a few parts in Spanish (the ones provided by wx i18n packages, like "File" menu), but the rest of the UI defaults to English.

After taking a look with strace, I've noticed that Dolphin didn't bothered to look for its locales at the expected place (in my case, /usr/local/share/locales/$LANG/LC_MESSAGES/dolphin-emu.mo). Instead it was looking at the other usual places (like /usr/share), and other unexpected places (/usr/local/share/dolphin-emu/user, seriously!?!?!). Attached is the full strace log.

What did you expect to happen instead?
Dolphin should run with the expected locales (es_VE, but since this doesn't exist, it should fallback to es)

What steps will reproduce the problem?

  1. Get a Debian testing/unstable setup
  2. Install wx3.0 from the repos
  3. Build Dolphin with that wx version
  4. Install and run
  5. Enjoy the missing locale

Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have
known issues and bugs, so don't report issues about them and test the
latest Dolphin version first.
Which versions of Dolphin did you test on?
4.0.534, just built from git-master

Does using an older version of Dolphin solve your issue? If yes, which
versions of Dolphin used to work?
My older builds with my locally-built wx2.9 used to work fine. Haven't tested with internal wx...

What are your PC specifications? (including, but not limited to: Operating
System, CPU and GPU)
Debian Jessie (testing) amd64
(ATM CPU/GPU isn't relevant to this issue, but if you insist: Core i5-2540M, Intel HD3000/nVidia 610M...)

Are you using the 32 or the 64 bit version of Dolphin?
64-bit

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)
run.log.bz2 (attached): strace log

Actions #1

Updated by tomman almost 11 years ago

After experiencing the same with another wx3.0 application built from source (Aegisub), it looks like this is a issue with Debian wx3.0 packages.

A workaround in this case is to install the locales to /usr/share, which means either changing the prefix for the entire application, or depending of the build system, using a parameter (in the case of autotools, --localedir). Sadly, Dolphin' cmake build system has no provisions for a separate locale directory.

I'll do more research on this, but feel free to flag this as a WONTFIX in the meanwhile, as it's more likely a Debian bug.

Actions #2

Updated by parlane almost 11 years ago

  • Status changed from New to New
Actions #3

Updated by tomman over 10 years ago

Found a workaround for this: instead of using make install, I just build a .deb package for this using cpack. This somehow sorts everything into the proper paths expected by Debian libs (plus it allows me to cleanly uninstall and update Dolphin).

Actions #4

Updated by phire over 9 years ago

  • Status changed from New to Won't fix
Actions

Also available in: Atom PDF