Re: sketch of i18n specification

Nathaniel Smith <njs@xxxxxxxxx> writes:

> On Tue, Nov 18, 2003 at 11:58:30AM -0500, graydon hoare wrote:
> ...
> >   - if a file has the persistent attribute "charset", its value will
> >     be used instead of the LC_CTYPE locale setting.
> 
> That's kind of wierd.  If I always want a file to be in some
> particular character set, why would I turn on character conversion in
> the first place?

*shrug* I thought some people might find themselves unhappy with
things inferred from LC_CTYPE (or any $ENV setting); just thought I'd
give a way to override it.

> Is there any benefit to storing files in the repository with non-UTF8
> encodings, but still allowing character conversion?  (I guess for
> those people whose LC_CTYPEs matched the repository encoding, this
> would make sha1sum work again.)

I suppose there might be. some people claim -- I've only heard it from
japanese people, but maybe there are others -- that their character
sets aren't all very well represented in unicode. perhaps the UTF-8
transform would be unacceptably lossy to them.

do you think it would be better *not* to specify the internal form,
but let a hook / attribute select it? in other words, specify an
incoming and an outgoing mapping function for each file?

> >   - subject to character set and line ending conversion unless
> >     overridden by a hook.
> 
> Err, so I can't put binary data in a cert?  What about test result
> files and the like?

... "unless overridden by a hook"

keep in mind, the current idea I'm gravitating towards for tests is
not to encode their results into certs per-se, but only the approval
or disapproval of an external rule ("no regressions since baseline
XXX").

(this item is here mostly because I'd like for it to remain possible
 to view most cert values -- especially changelog entries -- on a
 terminal)

-graydon