Internationalisation in pspp is complicated.
The most annoying aspect is that of character-encoding.
-This chapter attempts to describe the problems and current ways
+This chapter attempts to describe the problems and current ways
in which they are addressed.
@item The locale of the data. Only the character encoding is relevant.
@end itemize
-Each of these locales may, at different times take
+Each of these locales may, at different times take
separate (or identical) values.
-So for example, a French statistician can use pspp to prepare a report
-in the English language, using
-a datafile which has been created by a Japanese researcher hence
+So for example, a French statistician can use pspp to prepare a report
+in the English language, using
+a datafile which has been created by a Japanese researcher hence
uses a Japanese character set.
It's rarely, if ever, necessary to interrogate the system to find out
from the system locale if not set.
@subsection The output locale
-This locale is the one that should be visible to the person reading a
+This locale is the one that should be visible to the person reading a
report generated by pspp. Non-data related strings (Eg: ``Page number'',
``Standard Deviation'' etc.) will appear in this locale.
@section System files
@file{*.sav} files contain a field which is supposed to identify the encoding
-of the data they contain (@pxref{Machine Integer Info Record}).
+of the data they contain (@pxref{Machine Integer Info Record}).
However, many
files produced by early versions of spss set this to ``2'' (ASCII) regardless
of the encoding of the data.
Later versions contain an additional
record (@pxref{Character Encoding Record}) describing the encoding.
-When a system file is read, the dictionary's encoding is set using information
+When a system file is read, the dictionary's encoding is set using information
gleened from the system file.
-If the encoding cannot be determined or would be unreliable, then it
+If the encoding cannot be determined or would be unreliable, then it
remains unset.
@section GUI
-The psppire graphic user interface is written using the Gtk+ api, for which
+The psppire graphic user interface is written using the Gtk+ api, for which
all strings must be encoded in UTF8.
All strings passed to the GTK+/GLib library functions (except for filenames)
must be UTF-8 encoded otherwise errors will occur.
-Thus, for the purposes of the programming psppire, the user interface locale
+Thus, for the purposes of the programming psppire, the user interface locale
should be assumed to be UTF8, even if setlocale and/or nl_langinfo
indicates otherwise.
@subsection Filenames
The GLib API has some special functions for dealing with filenames.
-Strings returned from functions like gtk_file_chooser_dialog_get_name are not,
+Strings returned from functions like gtk_file_chooser_dialog_get_name are not,
in general, encoded in UTF8, but in ``filename'' encoding.
-If that filename is passed to another GLib function which expects a filename,
+If that filename is passed to another GLib function which expects a filename,
no conversion is necessary.
-If it's passed to a function for the purposes of displaying it (eg. in a
-window's title-bar) it must be converted to UTF8 --- there is a special
+If it's passed to a function for the purposes of displaying it (eg. in a
+window's title-bar) it must be converted to UTF8 --- there is a special
function for this: g_filename_display_name or g_filename_basename.
If however, a filename needs to be passed outside of GTK+/GLib (for example to fopen) it must be converted to the local system encoding.
Converts the string @var{text}, which is encoded in @var{from} to a new string encoded in @var{to} encoding.
If @var{len} is not -1, then it must be the number of bytes in @var{text}.
-It is the caller's responsibility to free the returned string when no
+It is the caller's responsibility to free the returned string when no
longer required.
@end deftypefun
-In order to minimise the number of conversions required, and to simplify
+In order to minimise the number of conversions required, and to simplify
design, PSPP attempts to store all internal strings in UTF8 encoding.
Thus, when reading system and portable files (or any other data source),
the following items are immediately converted to UTF8 encoding:
This makes it difficult (impossible?) to elegantly handle the issues.
For example, it would make sense for the gui's datasheet to display
numbers formatted according to the LC_NUMERIC category of the data locale.
-Instead however there is the @func{data_out} function
+Instead however there is the @func{data_out} function
(@pxref{Obtaining Properties of Format Types}) which uses the
-@func{settings_get_decimal_char} function instead of the decimal separator
-of the locale. Similarly, formatting of monetary values is displayed
+@func{settings_get_decimal_char} function instead of the decimal separator
+of the locale. Similarly, formatting of monetary values is displayed
in a pspp/spss specific fashion instead of using the LC_MONETARY category.
projects / pspp / blobdiff