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. _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
