Re: patch to gnustep-base (Unicode and others)

[Richard Frith-Macdonald]

On Sunday, April 7, 2002, at 04:24 PM, Serg Stoyan wrote:

> Hi, everybody!
>
> Here is a patch to the gnustep-base, whith additions such as:
>
> - fixes NSString's initWithCString* methods behaviour by commenting out
>   GSString's. Without it initWithCString* methods doesn't convert C 
> string
>   into Unicode and this is not OpenStep compliant;

Perhaps you can explain more ... as far as I cn see the above is simply
wrong.  Certainly initWithCString* methods are not supposed to convert to
unicode (as a general rule), and OpenStep doesn't say they should - so
I'm guessing you have some meaning in mind that is not immediately
obvious to me.

> - adds 2 languages into Resources/Languages: Russian and Ukrainian;

Thanks, but I can't use them ... as I don't know what encoding you have 
created
them in.  I have added a README file to the Resources/Languages 
subdirectory
to say what format language files *should* be in (and corrected some 
errors
in the existing files).

> - enables NSDictionary's initWithContentsOfFile read the language files
>   which contains non-latin characters (e.g. Russian and Ukrainian) by 
> using
>   default C string encoding;

The language files are property lists, and as such should not contain any
non-ascii characters (they should use \u escape sequence for unicode) ...
so this change should not be necessary.

That being said, I've been thinking about reverting the property list 
loading
methods in NSDictionary and NSArray to accepting non-ascii data.  I'm 
really
not sure what the best approach is.

On the one hand, it's convenient for people to be able to hand-edit 
property
lists using their local encoding,  On the other hand, if we allow that, 
they
will produce property lists which are non-portable.

I recently added a little tool 'cvtenc' to convert files from one 
encoding to another.
So I *think* the best thing is probably to stick to enforcing 
portability of
property lists, and use that tool (possibly with further improvements) 
before/after
hand editing them.  Certainly we need to do that for GNUstep 
resources ... since we
need them to be portable - but I remain uncertain about the best 
approach for
general users.

> - NSLog uses default C string encoding for dataUsingEncoding: now.

Added that.