<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 7, 2015 at 12:56 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hoi Karl,<br>
<br>
Tuesday, April 7, 2015, 9:42:34 PM, you wrote:<br>
<br>
> On Tue, Apr 7, 2015 at 11:22 AM, Hika van den Hoven <<a href="mailto:hikavdh@gmail.com">hikavdh@gmail.com</a>><br>
> wrote:<br>
<br>
>> Hoi Karl,<br>
>><br>
>> Tuesday, April 7, 2015, 8:01:30 PM, you wrote:<br>
>><br>
>> > On Tue, Apr 7, 2015 at 10:14 AM, Hika van den Hoven <<a href="mailto:hikavdh@gmail.com">hikavdh@gmail.com</a>><br>
>> > wrote:<br>
>><br>
>> >> 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>
>> ><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<br>
>> >> understand<br>
>> >> >> >>>> nl_NL.UTF-8. It tries to make it us_NL.UTF-8 which doesn't<br>
>> exist.<br>
>> >> ;(<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<br>
>> any<br>
>> >> >> >>> valid locale. (Since MythTV doesn't change any of what you set,<br>
>> I'm<br>
>> >> >> >>> assuming you understood my message to say that you have to use<br>
>> "us"<br>
>> >> 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<br>
>> 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<br>
>> /not/<br>
>> >> >> > nl_NL.UTF-8. It will /only/ complain when it's not set to the<br>
>> right<br>
>> >> >> > value, so if you're getting the warning, you (or your distro) have<br>
>> got<br>
>> >> >> > it set incorrectly (for Qt's needs). It's possible Qt's code has<br>
>> been<br>
>> >> >> > updated so that it will all handle UTF8 as well as UTF-8 (the<br>
>> hyphen<br>
>> >> >> > being the thing that's required, not the capitalization), but some<br>
>> >> parts<br>
>> >> >> > of Qt didn't when the code was added to MythTV to give that<br>
>> warning,<br>
>> >> so<br>
>> >> >> > MythTV explicitly tells people to set it in a way that it will<br>
>> always<br>
>> >> >> > work, on any distro or any Unix-like OS. Things /will/ go wrong if<br>
>> 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<br>
>> >> they<br>
>> >> >> > don't notice issues, they think all is good. But, hey, if you<br>
>> don't<br>
>> >> >> > notice any problems, that means everything's good, right? Just ask<br>
>> >> 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<br>
>> 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>
>> >> I do seem to recall fighting with this a bit, but eselect locale offers<br>
>> > 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<br>
>> 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<br>
>> automatically<br>
>> > # rebuilt for you. After updating this file, you can simply run<br>
>> > `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>
>> > 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>
>> Looks OK. I now have only LANG="nl_NL.UTF-8" in there. And it's in<br>
>> essence the same as mine. I only have three dutch strings extra:<br>
>> UTF-8, iso8858-1 and iso8859-15. But I normally only use dutch utf.<br>
>><br>
>> What does eselect locale list offer on your system?<br>
>><br>
>> $ eselect locale list<br>
> Available targets for the LANG variable:<br>
> [1] C<br>
> [2] POSIX<br>
> [3] en_US<br>
> [4] en_US.iso88591<br>
> [5] en_US.utf8<br>
> [6] en_US.UTF-8 *<br>
> [ ] (free form)<br>
<br>
So you also have that wrong utf8 string. You also added the right one<br>
by hand (free form)? I Have these the nl_NL variants including 8859-15<br>
(with euro) and 'dutch' I guess that's the outdated alias pointing to<br>
nl_NL.iso-8859-1. Nothing hinting to nl_US??<br>
<br></blockquote></div>I can't remember. I may have typed it as "free form". I know I did have it set to the utf8 string and was baffled why myth was still complaining because that was the only UTF-8 option offered by the system. Also I think I discovered that for some stupid reason it appears to be case sensitive in addition to needing the hyphen. Yay, standards!<br><br></div><div class="gmail_extra">Karl<br></div></div>