Re: Problem loading German settings

[Richard Frith-Macdonald]

On Saturday, March 30, 2002, at 07:45 PM, Fred Kiefer wrote:

> Hi Richard,
>
> back on my Linux machine I find so problems to run GNUstep with German
> as the selected language:
>
> address@hidden:/usr/src/gnustep/usr-apps/examples/gui> LANG=de_DE
> address@hidden:/usr/src/gnustep/usr-apps/examples/gui> openapp
> GSTest/GSTest.app/
> 03 30 19:20:27 GSTest[6203] File NSDictionary.m: 458. In [GSDictionary
> -initWithContentsOfFile:] Contents of file
> '/usr/GNUstep/System/Libraries/Resources/Languages/German' does not
> contain a dictionary
> address@hidden:/usr/src/gnustep/usr-apps/examples/gui> LANG=en_GB
> address@hidden:/usr/src/gnustep/usr-apps/examples/gui> openapp
> GSTest/GSTest.app/
> address@hidden:/usr/src/gnustep/usr-apps/examples/gui> LANG=fr_FR
> address@hidden:/usr/src/gnustep/usr-apps/examples/gui> openapp
> GSTest/GSTest.app/
> 03 30 19:21:55 GSTest[6255] File NSDictionary.m: 458. In [GSDictionary
> -initWithContentsOfFile:] Contents of file
> '/usr/GNUstep/System/Libraries/Resources/Languages/French' does not
> contain a dictionary
>
> My feeling is that this is caused by some of your latest changes. Now a
> property list file must either be ASCII or UTF8, while our language file
> are still ISO Latin 1 encoded. Is there any simple method to convert
> them? (recode, iconv ?) Or should we use the \U escape sequence here?
>
> I am also wondering, why I am the first to have this problem. Did we
> loose all our European users

I've had one other report, and I've been thinking abut this problem for 
quite some time now.

As I understand it ...
OpenStep style property lists should either be 16-bit unicode or be 
ascii using \U escape
sequences for non-ascii characters.
MacOS-X style XML property lists should be UTF8 anyway.

These are portable formats ... if our files use any other encoding, we 
have the problem
that, when a user sets a different default cstring encoding, the data 
read in from the
files will be incorrect :-(

I *think* this means that our language files are wrong.  However I'm not 
sure - it's certainly
much easier to edit files using your default encoding - but I can see no 
mechanism to ensure
that people using other encodings get to see the correct thing.

I'm wondering if I should just revert to loading the files as data in 
the current default
encoding, and accepting that this will mean that they will contain 
garbage as far as people
using other encodings are concerned.  In the worst case, where someone 
is using an encoding
which does not contain ascii as a subset, property lists will be 
unparsable rather than just
containing strings with incorrect characters.

I seem to recall NeXT recommending that people store this stuff in 
unicode (16-bit) encoding.
This would make sense if their implementation loaded non-unicode 
property-list files using the
default C string encoding, and was therefore potentially non-portable.

So perhaps we should be storing our language files in unicode.  We could 
include a couple of
tools with the base library, to convert between unicode and cstring 
encodings, so we could
edit using native tools and convert to unicode when done.

Unless someone has a better idea, what I propose to do is -

1. Revert property-list loading to using the default cstring encoding 
for non-unicode files.
So property-list files would be able to be edited using local encoding, 
giving convenience
at the expense of being non-portable to systems where the default 
encoding is different.

2. Add gsutoc and gsctou conversion tools in the base package.

3. Convert language (.strings) and property list (.plist) files from 
Latin1 to 16-bit unicode.
So all the GNUstep system files would be portable.