Robert Dodier wrote:
> On Wed, Feb 11, 2009 at 10:10 AM, Raymond Toy <raymond.toy at ericsson.com> wrote:
>
>
>>> I dunno. At this point I'd rather just nuke any characters that are
>>> not 7-bit ascii.
>>>
>
>
>> I've done that already.
>>
>> But I think that we're going to have to visit this issue again soon if
>> you get the gettext stuff going with different translations.
>>
>> I don't know, but I suspect that the supported languages are not going
>> to fit in 7-bit ascii, so we'll have to set up the output streams to
>> support the correct external format.
>>
>
> Sure, but I think there are 2 separate problems here.
>
> One is to read the source code in any locale. I think enforcing
> 7-bit ascii is helpful for that.
>
7-bit ascii, with Unix end-of-lines, not DOS, not Mac, right?
That works for me, since I'm illiterate. May not be so nice for people
who are not.
> The other is to read and display translated messages.
> For any given language that would be done in a specific locale.
> It doesn't have to work in any other locale.
>
Yes.
As a side note not really related but cmucl had an experimental unicode
version that supported the concept of dialect. That is, the standard
common lisp functions had a "native" word for each function. When read,
it would get translated to the correct name, and on printing it would
get the native word.
And I can imagine that once we have messages in native languages, people
will want to use variable names in the native language. Eventually
we'll probably have to do this and it's not such a stretch then to allow
source code to use other languages.
The core maxima language, however, should probably remain plain
English. Any add-on share/contrib packages can use whatever language is
desired.
Anyway, that's probably a long way off.
Ray