Summary | Use portable charset names |
Queue | Horde Base |
Queue Version | HEAD |
Type | Bug |
State | Resolved |
Priority | 2. Medium |
Owners | jan (at) horde (dot) org |
Requester | mbydalek (at) mobilemini (dot) com |
Created | 12/16/2004 (7524 days ago) |
Due | |
Updated | 11/24/2006 (6816 days ago) |
Assigned | 02/08/2005 (7470 days ago) |
Resolved | 11/24/2006 (6816 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Resolved
New Attachment: charsets.diff
like this diff work?
ISO_xxx versions there (in /usr/share/locale). Is this something
that's changed in FreeBSD since this bug was reported? Or is it those
symlinks that don't work?
ISO_xxx versions there (in /usr/share/locale). Is this something
that's changed in FreeBSD since this bug was reported? Or is it those
symlinks that don't work?
charset names in nls.php.dist that administrators can uncomment.
Queue ⇒ Horde Base
Priority ⇒ 2. Medium
Version ⇒ HEAD
because it doesn't recognize locale aliases and default charsets.
I want to fix it anyway, because it pointed me to the problem that the
charsets we are using are not working on BSD systems. But that's a
Horde problem, not a Chora problem.
problem with Chora HEAD on an OpenBSD 3.7 server. I've tried editing
$nls['defaults']['charset'], but it made no difference.
Thanks,
Jason
State ⇒ Assigned
That is what was breaking things on FreeBSD. I changed the default
charset in my nls.php to ISO8859-1 and it works like a charm now.
noticed that the exact same setup worked just fine in Linux, so the
problem was with FreeBSD (of course the 2 machines we tested on).
It seems that FreeBSD handles locales differently than Linux by doing
"LanguageCode_CountryCode.Encoding" rather than just
"LanguageCode_CountryCode"
So, I see that the "en_US" alias is set in config/nls.php. I'm not
sure if you would like me to do anything, but it might be worth
putting a note in that for FreeBSD, you must change this setting to
one of "en_US.{US-ASCII, ISO8859-1, ISO8859-15}"
Thanks
State ⇒ Not A Bug
If you have the en_US locale correctly installed, this must be a bug
in Subversion.
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Queue ⇒ Chora
Type ⇒ Bug
Summary ⇒ SVN and LANG variable
but a PHP one. Basically, I'm trying to use a subversion source with
Chora, but I get:
svn: error: cannot set LC_ALL locale
svn: error: environment variable LANG is en_US
svn: error: please check that your locale name is correct
Basically, the LANG variable is set to en_US, which svn doesn't like
as a locale. So what I've done is go through the code to do "unser
LANG && " <run svn binary>
I'm not sure what sets this LANG variable, but if you could provide
any help, that'd be wonderful :)
Thanks.