Tickets :: [#984] Use portable charset names

6.0.0-beta1

10/31/25

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 (7624 days ago)
Due
Updated	11/24/2006 (6916 days ago)
Assigned	02/08/2005 (7570 days ago)
Resolved	11/24/2006 (6916 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

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	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.