<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 7, 2015 at 10:14 AM, Hika van den Hoven <span dir="ltr"><<a href="mailto:hikavdh@gmail.com" target="_blank">hikavdh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hoi Karl,<br>
<br>
Tuesday, April 7, 2015, 7:09:07 PM, you wrote:<br>
<br>
> On Tue, Apr 7, 2015 at 9:53 AM, Hika van den Hoven <<a href="mailto:hikavdh@gmail.com">hikavdh@gmail.com</a>><br>
> wrote:<br>
<br>
>> Hoi Michael,<br>
>><br>
>> Tuesday, April 7, 2015, 6:43:52 PM, you wrote:<br>
>><br>
>> > On 04/07/2015 11:25 AM, Hika van den Hoven wrote:<br>
>> >> Hoi Michael,<br>
>> >><br>
>> >> Tuesday, April 7, 2015, 5:18:35 PM, you wrote:<br>
>> >><br>
>> >>> On 04/07/2015 11:03 AM, Hika van den Hoven wrote:<br>
>> >>>> It then doesn't do so good a job outside the US. It doesn't understand<br>
>> >>>> nl_NL.UTF-8. It tries to make it us_NL.UTF-8 which doesn't exist. ;(<br>
>> >>> You don't have to use us.  You'd use:<br>
>> >>> export LC_ALL=nl_NL.UTF-8<br>
>> >>> export LANG=nl_NL.UTF-8<br>
>> >>> The only part you have to have is the UTF-8 (encoding) part--and any<br>
>> >>> valid locale.  (Since MythTV doesn't change any of what you set, I'm<br>
>> >>> assuming you understood my message to say that you have to use "us" in<br>
>> >>> there somewhere?)<br>
>> >> No It is set to nl_NL.UTF-8, but always complains it cannot find<br>
>> >> us_NL.UTF-8. Which is correct for it does not exist. And everything<br>
>> >> seems to go OK, so it's not more then annoying.<br>
>><br>
>> > No, I'm guessing it's set for nl_NL.UTF8 or nl_NL.utf8, which is /not/<br>
>> > nl_NL.UTF-8.  It will /only/ complain when it's not set to the right<br>
>> > value, so if you're getting the warning, you (or your distro) have got<br>
>> > it set incorrectly (for Qt's needs).  It's possible Qt's code has been<br>
>> > updated so that it will all handle UTF8 as well as UTF-8 (the hyphen<br>
>> > being the thing that's required, not the capitalization), but some parts<br>
>> > of Qt didn't when the code was added to MythTV to give that warning, so<br>
>> > MythTV explicitly tells people to set it in a way that it will always<br>
>> > work, on any distro or any Unix-like OS. Things /will/ go wrong if Qt<br>
>> > doesn't pick up the right encoding--even if you don't notice things<br>
>> > going wrong.<br>
>><br>
>> > Unfortunately, though, users can't seem to figure out that UTF8 !=<br>
>> > UTF-8, then write off the warning as "just more MythTV brokenness"<br>
>> > because obviously the problem can't be my configuration.  And, when they<br>
>> > don't notice issues, they think all is good.  But, hey, if you don't<br>
>> > notice any problems, that means everything's good, right?  Just ask any<br>
>> > smoker.<br>
>><br>
>> It seems you're right. I did a qt upgrade last week (4.8.5 to 4.8.6)<br>
>> and it now sings a different tune. It's no longer talking about<br>
>> us_NL.UTF-8 but about nl_NL.utf8 and that's a first. I before tried<br>
>> changing the string without effect? I'll try again.<br>
>><br>
<br>
> Hika,<br>
<br>
> Check `eselect locale` on Gentoo. Pick the one with "UTF-8". That may be<br>
> all you need.<br>
<br>
> Karl<br>
<br>
Thanks, I know, but even though I set it right in /etc/locale.gen<br>
locale-gen changes the strings.<br>
I have<br>
en_US.UTF-8 UTF-8<br>
nl_NL.UTF-8 UTF-8<br>
and some others in there, but eselect only offers em_US.utf8 and<br>
nl_NL.utf8 (and those others for iso8859)<br>
<br></blockquote></div>I do seem to recall fighting with this a bit, but eselect locale offers en_US.UTF-8 on my system. Here's my /etc/locale.gen:<br><br># /etc/locale.gen: list all of the locales you want to have on your system<br>#<br># The format of each line:<br># <locale> <charmap><br>#<br># Where <locale> is a locale located in /usr/share/i18n/locales/ and<br># where <charmap> is a charmap located in /usr/share/i18n/charmaps/.<br>#<br># All blank lines and lines starting with # are ignored.<br>#<br># For the default list of supported combinations, see the file:<br># /usr/share/i18n/SUPPORTED<br>#<br># Whenever glibc is emerged, the locales listed here will be automatically<br># rebuilt for you.  After updating this file, you can simply run `locale-gen`<br># yourself instead of re-emerging glibc.<br><br>en_US ISO-8859-1<br>en_US.UTF-8 UTF-8<br>#ja_JP.EUC-JP EUC-JP<br>#ja_JP.UTF-8 UTF-8<br>#ja_JP EUC-JP<br>#en_HK ISO-8859-1<br>#en_PH ISO-8859-1<br>#de_DE ISO-8859-1<br>#de_DE@euro ISO-8859-15<br>#es_MX ISO-8859-1<br>#fa_IR UTF-8<br>#fr_FR ISO-8859-1<br>#fr_FR@euro ISO-8859-15<br>#it_IT ISO-8859-1<br><br><br></div><div class="gmail_extra">And here's /etc/env.d/02locale:<br>LANG="en_US.UTF-8"<br>LC_COLLATE="C"<br>#LC_CTYPE="en_US.UTF-8"<br>#LC_ALL=en_US.UTF-8<br><br></div></div>