Okay, I've committed that patch and we'll see what feedback we get.

I didn't test it, but yes, I guess.

Okay, let's see if I'm starting to understand this. Would something 
like this diff work?

Neither, both don't work because we use iso-xxx-xxx, not iso_xxx-xxx.

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?

It would probably sufficient to provide a set of FreeBSD compatible 
charset names in nls.php.dist that administrators can uncomment.

Jan, do you know what the fix for this would be?

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.

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

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.

This is exactly what we do. en_US.ISO-8859-1 btw.

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

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.

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.