6.0.0-beta1
7/23/25

[#984] Use portable charset names
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

History
11/24/2006 08:55:55 PM Chuck Hagenbuch Comment #14
State ⇒ Resolved
Reply to this comment
Okay, I've committed that patch and we'll see what feedback we get.
11/24/2006 04:23:08 PM Jan Schneider Comment #13 Reply to this comment
I didn't test it, but yes, I guess.
11/24/2006 04:07:23 PM Chuck Hagenbuch Comment #12
New Attachment: charsets.diff Download
Reply to this comment
Okay, let's see if I'm starting to understand this. Would something 
like this diff work?
11/24/2006 10:30:04 AM Jan Schneider Comment #11 Reply to this comment
If I look at the locales on coyote, it has both the ISOxxx and the
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?
Neither, both don't work because we use iso-xxx-xxx, not iso_xxx-xxx.
11/24/2006 05:02:42 AM Chuck Hagenbuch Comment #10 Reply to this comment
If I look at the locales on coyote, it has both the ISOxxx and the 
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?
11/23/2006 05:25:28 PM Jan Schneider Comment #9 Reply to this comment
It would probably sufficient to provide a set of FreeBSD compatible 
charset names in nls.php.dist that administrators can uncomment.
11/23/2006 05:16:22 PM Chuck Hagenbuch Comment #8 Reply to this comment
Jan, do you know what the fix for this would be?
10/13/2005 07:57:30 AM Jan Schneider Summary ⇒ Use portable charset names
 
10/13/2005 07:56:39 AM Jan Schneider Comment #7
Queue ⇒ Horde Base
Priority ⇒ 2. Medium
Version ⇒ HEAD
Reply to this comment
After investigating this more, I decided that this is a bug in SVN 
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.
08/17/2005 02:20:47 PM jason (at) dixongroup (dot) net Comment #6 Reply to this comment
Are there any impending fixes for this?  I'm encountering this same 
problem with Chora HEAD on an OpenBSD 3.7 server.  I've tried editing 
$nls['defaults']['charset'], but it made no difference.



Thanks,

Jason
02/08/2005 09:15:44 AM Jan Schneider Assigned to Jan Schneider
State ⇒ Assigned
 
12/21/2004 04:24:45 PM rwallace (at) thewallacepack (dot) net Comment #5 Reply to this comment
The charset is actually ISO8859-1, without a dash after the ISO part.   
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.
12/17/2004 11:39:22 PM Jan Schneider Comment #4 Reply to this comment
This is exactly what we do. en_US.ISO-8859-1 btw.
12/17/2004 10:30:46 PM mbydalek (at) mobilemini (dot) com Comment #3 Reply to this comment
Well no, it's not a subversion bug.  After doing some testing, we 
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
12/17/2004 08:58:25 PM Jan Schneider Comment #2
State ⇒ Not A Bug
Reply to this comment
The LANG variable is necessary for all of the localization features. 
If you have the en_US locale correctly installed, this must be a bug 
in Subversion.
12/16/2004 08:11:54 PM mbydalek (at) mobilemini (dot) com Comment #1
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Queue ⇒ Chora
Type ⇒ Bug
Summary ⇒ SVN and LANG variable
Reply to this comment
Let me start off by saying that this *may* not be a Horde bug at all, 
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.

Saved Queries