Bug 92142

Summary:	PulseAudio v7 doesn't load locales
Product:	PulseAudio	Reporter:	Jan Alexander Steffens (heftig) <jan.steffens>
Component:	build-system	Assignee:	pulseaudio-bugs
Status:	RESOLVED FIXED	QA Contact:	pulseaudio-bugs
Severity:	normal
Priority:	medium	CC:	bugzilla, lennart, piotrdrag, rdieter
Version:	unspecified	Keywords:	i18n, l10n
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	92139

Description Jan Alexander Steffens (heftig) 2015-09-27 16:20:33 UTC

Apparently DATADIRNAME in configure is empty now, so it sets PULSE_LOCALEDIR to /usr//locale here (Arch Linux).

Passing DATADIRNAME=share to configure makes it work.

Downstream Bug: https://bugs.archlinux.org/task/46452

Comment 1 Tanu Kaskinen 2015-09-27 16:47:54 UTC

And the only difference between working and non-working setups is the PulseAudio upgrade? "git diff v6.0..v7.0 -- configure.ac" doesn't show any relevant changes... Also, installing with default configure options (to /usr/local) works for me.

Anyway, I don't know why we use ${prefix}/${DATADIRNAME} instead of just ${datadir}. Does changing that fix the issue too?

Comment 2 Tanu Kaskinen 2015-09-27 16:56:42 UTC

It looks like the modern way is to use localedir[1], so there's no need to define pulselocaledir at all. And instead of PULSE_LOCALEDIR, we should use LOCALEDIR.

[1] https://www.gnu.org/software/gettext/manual/html_node/src_002fMakefile.html

Comment 3 Jan Alexander Steffens (heftig) 2015-09-27 16:59:28 UTC

Using pulselocaledir='${datarootdir}/locale' seems to work:
#define PULSE_LOCALEDIR "/usr/share/locale"

Using pulselocaledir='${localedir}' results in:
#define PULSE_LOCALEDIR "${prefix}/share/locale"
I.e., the dir isn't completely expanded.

There doesn't seem to be a LOCALEDIR.

Comment 4 Tanu Kaskinen 2015-09-29 08:43:53 UTC

I submitted a patch that moves PULSE_LOCALEDIR definition from configure.ac to src/Makefile.am: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/24182

Comment 5 Tanu Kaskinen 2016-11-27 15:37:31 UTC

The patch has been applied, so I think this bug can be closed.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.