Understanding locale so I can ignore a MythTV message

English Multimedia
#1

Specs: My OS is 13.2 with all the latest updates.

Hi,

I’m in the process of setting up MythTV on my system and there’s plenty of issues to work through – I still haven’t got past the backend setup.

In the process of all this the setup suggested I run mythfilldatabase, so I did.

As it was running this message came up:

This application expects to be running a locale that specifies a UTF-8 codeset, and many features may behave improperly with your current language settings. Please set the LANG variable(s) in the environment in which this program is executed to include a UTF-8 codeset (such as ‘en_US.UTF-8’).

so I did a “locale” and it returned this:

LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Researching it there’s a fairly easy way to change this by simply running the command:

localedef -i en_US -f UTF-8 en_US.UTF-8

however doing a little further digging I’m not sure if this is what I want to do.

My understanding is that the reason that local is set to POSIX is that Linux can make intelligent decisions on a character encoding (and probably other things to do with locale) rather than be stuck in UTF-8.

Thinking this it would seem me that Linux would serve up UTF-8 if needed so that MythTV will be just fine so it should be fine if I leave the locale as is.

However, this is just my best guess based on what I have read so far so and I would appreciate some knowledge from someone who knows for sure, or at least has a better informed judgement than my 1 hour or so of reading up on the issue.

That being said, if that’s not the case and MythTV should really be given the character encoding that it wants then perhaps someone knows how to do that just for that program rather than making a system wide change.

Finally, when I did run

localedef -i en_US -f UTF-8 en_US.UTF-8

I got the error message:

character map file UTF-8' not found: No such file or directory cannot read character map directory /usr/share/i18n/charmaps’: No such file or directory
so if someone knows whether that’s something I should be concerned about please to let me know.

#2

Maybe you want something to compare with:

henk@boven:~> locale
LANG=nl_NL.UTF-8
LC_CTYPE="nl_NL.UTF-8"
LC_NUMERIC="nl_NL.UTF-8"
LC_TIME="nl_NL.UTF-8"
LC_COLLATE="nl_NL.UTF-8"
LC_MONETARY="nl_NL.UTF-8"
LC_MESSAGES="nl_NL.UTF-8"
LC_PAPER="nl_NL.UTF-8"
LC_NAME="nl_NL.UTF-8"
LC_ADDRESS="nl_NL.UTF-8"
LC_TELEPHONE="nl_NL.UTF-8"
LC_MEASUREMENT="nl_NL.UTF-8"
LC_IDENTIFICATION="nl_NL.UTF-8"
LC_ALL=
henk@boven:~>

Take care, this is (of course) as it is set, at the moment, for user henk. Locale may be different for the system (and of course for other users).
User henk uses KDE and got this by using KDE’s System Settings > Country/Language.

On the same system as user root:

boven:~ # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
boven:~ #

Thus same as yours (I assume what you posted was also done as root, but as you did only post the output and not the prompts and the command, we have to guess those things).

It says already

LC_CTYPE=en_US.UTF-8

thus I wonder why the application mutters.

In general, Linux is always using UTF-8. Applications may do otherwise. E.g. Browsers generally try to adapt to what the HTTP header (or even a HTML <meta http-equiv=“Content-Type” content="…"> ) tells them the contents of the page is.

#3

As hcvv already suggested, I would guess as well that you are running this as root. root normally uses POSIX as locale (except for LC_CTYPE), which does not at all support UTF-8 I think.
Have a look at YaST->System->Language->Details, and set the option “Locale Settings for root” to yes. That should help I suppose.

Or set the LC_ALL variable manually to override all locale settings, i.e. run your program like this:

LC_ALL=en_US.UTF-8 *program*

(or run “export LC_ALL=en_US.UTF-8” in the same shell before you run your program).

Although I think just setting LANG should be sufficient…

LANG=en_US.UTF-8 *program*

Install the package glibc-i18ndata:

# rpm -qf /usr/share/i18n/charmaps
glibc-i18ndata-2.19-16.9.1.noarch
#4

It was the output for root. I didn’t know that the system would give root a different locale than regular users so I never even thought to look at different users’ locale.

Thanks for all your help!

#5

On 2015-05-06 02:06, Reg gie wrote:
>
> It was the output for root. I didn’t know that the system would give
> root a different locale than regular users so I never even thought to
> look at different users’ locale.

The assumption is that root should know English to read the manuals,
while the users have their choices :wink: :-p

And maybe because not all (old) programs used for administration support
utf-8.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#6

To many Linux users forget that they use a multi-user system. Every user has it’s own environment.

A user loging in from Australia and one from England, on the same system, both want to see their own time zone.

A Hindi speaking user login in and a Russion speaking user loging in, on the same system, want to see and use their own script and language.

Etc., etc.

#7

On 2015-05-06 10:56, hcvv wrote:

> To many Linux users forget that they use a multi-user system. Every user
> has it’s own environment.
>
> A user loging in from Australia and one from England, on the same
> system, both want to see their own time zone.
>
> A Hindi speaking user login in and a Russion speaking user loging in, on
> the same system, want to see and use their own script and language.
>
> Etc., etc.

True.

But the curious thing is that (I understand) the recommendation is to
keep root at POSIX.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#8

Probably for compatibility reasons, as you hinted at earlier already, but not just because of UTF-8. E.g. the sorting works different in different locales, this might break system stuff (f.i. old scripts that are not aware of that…).
Scripts/services might parse the output of commands they run, this might break when the output suddenly is in german and not english.
And so on.

That said, I did enable the standard locale for root here some time ago, and haven’t encountered any problems.
I suppose one cannot make a general statement out of this though.

#9

On 2015-05-06 14:56, wolfi323 wrote:

…

> Scripts/services might parse the output of commands they run, this might
> break when the output suddenly is in german and not english.
> And so on.

Yes, true, I have seen this happen.

> That said, I did enable the standard locale for root here some time ago,
> and haven’t encountered any problems.
> I suppose one cannot make a general statement out of this though.

But your locale is English or something else?

Because I would never set root’s locale for something that is not
English… Translation of man/info pages is hopeless. Programs are
better, but I know that there are translation errors in zypper/yast…
(I know because I’m one of the translators).

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#10

I have to say though that I consider this a bug in the corresponding script/whatever.
If it expects a specific locale, it should set it. If it expects some particular output of a command it runs, it should set $LANG for that command accordingly.

> That said, I did enable the standard locale for root here some time ago,
> and haven’t encountered any problems.
> I suppose one cannot make a general statement out of this though.

But your locale is English or something else?

No, german.

Because I would never set root’s locale for something that is not
English… Translation of man/info pages is hopeless.

Hm. Most are not translated anyway.
And most of the time I’m reading man/info pages as user, so this is not affected at all by root’s locale settings… :wink:

Programs are better, but I know that there are translation errors in zypper/yast…

Well, I don’t know what errors you mean specifically, but this depends on the used locale too I suppose.
I did notice some translation errors, but nothing I couldn’t handle/understand nevertheless…

And again, the same applies to any user, but a normal user probably would mostly use other programs than root does.

It’s probably more a matter of taste if you want to keep the language to english (for root, or maybe even for your user) because of that.