[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem loading German settings
From: |
Richard Frith-Macdonald |
Subject: |
Re: Problem loading German settings |
Date: |
Fri, 5 Apr 2002 09:22:47 +0100 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Problem loading German settings,
Richard Frith-Macdonald <=