I looked up that bug thread and did the check (by putting locale in the 
pre_build hook) but it gave the same info as when I SSH'd in (en_US.UTF-8 
everywhere).

DB:
show server_encoding;

server_encoding 
-----------------
 UTF8
(1 row)

show all;     // only lc_*
 lc_collate                      | en_US.UTF-8                             
                                    | Shows the collation order locale.
 lc_ctype                        | en_US.UTF-8                             
                                    | Shows the character classification 
and case conversion locale.
 lc_messages                     | en_US.utf8                               
                                   | Sets the language in which messages 
are displayed.
 lc_monetary                     | en_US.utf8                               
                                   | Sets the locale for formatting 
monetary amounts.
 lc_numeric                      | en_US.utf8                               
                                   | Sets the locale for formatting numbers.
 lc_time                         | en_US.utf8                               
                                   | Sets the locale for formatting date 
and time values.

Any difference between UTF-8 and utf8?
Is that all?


On Wednesday, July 2, 2014 9:12:05 PM UTC+2, Kenneth Bolton wrote:
>
> During my research earlier, I found a thread where someone was having 
> similar problems. Funny thing was that his locale was fine when ssh'd in, 
> but borked in his application. 
> https://bugzilla.redhat.com/show_bug.cgi?id=904077
>
> I think the next likely culprit is your database's encoding. Can you check 
> that?
>
> Django (and Mezz, which is just a Django application) will use the LANG, 
> as far as I know. 
>
>
> On Wed, Jul 2, 2014 at 3:04 PM, Fredrik Blomqvist <[email protected] 
> <javascript:>> wrote:
>
>> It's okay, I'm so glad you care to help me at all.
>>
>> I ran that (successfully) and then restarted everything. No success.
>> This is what "locale" outputs:
>> LANG=en_US.UTF-8
>> LC_CTYPE="en_US.UTF-8"
>> LC_NUMERIC="en_US.UTF-8"
>> LC_TIME="en_US.UTF-8"
>> LC_COLLATE="en_US.UTF-8"
>> LC_MONETARY="en_US.UTF-8"
>> LC_MESSAGES="en_US.UTF-8"
>> LC_PAPER="en_US.UTF-8"
>> LC_NAME="en_US.UTF-8"
>> LC_ADDRESS="en_US.UTF-8"
>> LC_TELEPHONE="en_US.UTF-8"
>> LC_MEASUREMENT="en_US.UTF-8"
>> LC_IDENTIFICATION="en_US.UTF-8"
>> LC_ALL=en_US.UTF-8
>>
>> This further strengthens my theory that the system is correctly 
>> configured, but Django/Mezzanine is not. Though with my level of knowledge 
>> in this particular area my theory is probably worth zero. Isn't there any 
>> way to force Django/Mezzanine to use UTF-8?
>>
>>
>> On Wednesday, July 2, 2014 8:25:15 PM UTC+2, Kenneth Bolton wrote:
>>
>>>
>>> On Wed, Jul 2, 2014 at 1:52 PM, Fredrik Blomqvist <fredrik.bl...@gmail.
>>> com> wrote:
>>> >
>>> > Oh you…if only I had permissions to sudo.
>>>
>>> Pardon my ignorance of OpenShift.
>>>
>>> How about:
>>> $ rhc env set LC_ALL=en_US.UTF-8
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to