Eric Covener wrote: > On 6/25/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >> * At run-time this should probably be determined by parsing first the >> LC_CTYPE, or LC_ALL in it's absense, or the fallback to the LANG >> envvar if neither LC_ variable is defined. The codepage follows >> the period, e.g. LANG=en_US.UTF-8 would be parsed as 'UTF-8'. > > Wouldn't runtime checks would mean xlate/xlate.c needs to find a new > way to figure out what the codepage of the source code was (to > translate compiled-in strings)? > > Perhaps APR_DEFAULT_CHARSET could be split into two different > identifiers APR_CURRENT_CHARSET/APR_BUILD_CHARSET that xlate callers > would have to think about.
I'm confused. APR messages are all english (regrettably) in US-ASCII. clib-errstring messages should respect LC_CTYPE for most modern, dynamic c libraries, no?
