[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: i18n

From: John Darrington
Subject: Re: i18n
Date: Sat, 27 May 2006 10:31:30 +0800
User-agent: Mutt/1.5.4i

I'm looking at i18n again, particularly from the point of view of the
gui.  I think we sort of came to a concensus on the text below.
Perhaps we ought to copy it into a readme file somewhere.

I want to go ahead and implement SET LOCALE.  It seems that SPSS (for
Windoze) accepts as arguments to SET LOCALE only a few keywords.  Ie
propose that we implement it such that it takes a string.  Eg:

SET LOCALE = 'de_DE'. or
SET LOCALE = 'jp'.

and also allow GERMAN, JAPANESE and ENGLISH as synonyms for "de", "jp"
and "en" respectively.

There are some other issues which have become apparent, in some
experiments I've been doing recently.  In particular, I'm in two minds
whether PSPP should take any notice of any aspect of the given locale
other than its character encoding.  But that's probably a topic that
should be discussed seperately.


On Sun, Mar 19, 2006 at 05:26:47PM -0800, Ben Pfaff wrote:
     Let me elaborate.  Here is the plan that I envision:
     i. PSPP adopts a single locale that defaults to the system locale
        but can be changed with SET LOCALE.  (I'll call this the "PSPP
     ii. All string data in all casefiles and dictionaries is in the
         PSPP locale, or at least we make that assumption.
     iii. The GET command assumes by default that data read in is in
          the PSPP locale.  If the user provides a LOCALE subcommand
          specifying something different, then missing values and
          value label keys are converted as the dictionary is read and
          string case data is converted "on the fly" as data is read
          from the file.  We can also provide a NOCONVERT subcommand
          (with a better name, I hope) that flags string variables
          that are not to be converted.
     iv. The SAVE command assumes by default that data written out is
         to be in the PSPP locale.  If the user provides a LOCALE
         subcommand specifying something different, then we convert
         string data, etc., as we write it, and again exceptions can
         be accommodated.
     v. Users who want accurate translations, as in your survey
        example, choose a reasonable PSPP locale, e.g. something based
        on UTF-8.
     vi. We look into the possibility of tagging system files with a
         locale.  The system file format is extensible enough that
         this would really just be a matter of testing whether SPSS
         will complain loudly about our extension records or just
         silently ignore them.

PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: pgpVK2NBn5RFZ.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]