From keld@dkuug.dk Fri Jun 17 09:35:05 1994
Received: by dkuug.dk id AA20061
  (5.65c8/IDA-1.4.4j for i18n@dkuug.dk); Fri, 17 Jun 1994 07:35:06 +0200
Message-Id: <199406170535.AA20061@dkuug.dk>
From: keld@dkuug.dk (Keld J|rn Simonsen)
Date: Fri, 17 Jun 1994 07:35:05 +0200
In-Reply-To: ALB@immedia.ca
       "(TC304.188) Decimal delimiter: presentation params should not force input" (Jun 16, 15:07)
X-Charset: ASCII
X-Char-Esc: 29
Mime-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Mnemonic-Intro: 29
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: ALB@immedia.ca, bealle@torolab6.vnet.ibm.com, cpwg-mail@revcan.ca,
        paref@vm1.ulaval.ca, umavs@torolab6.vnet.ibm.com
Subject: Re: (TC304.188) Decimal delimiter: presentation params should not force input
Cc: i18n@dkuug.dk, sc22wg20@dkuug.dk, tc304@dkuug.dk

ALB@immedia.ca writes:

> Subject  : Problem of the decimal delimiter function on input: i18n issue

Another way of solving this would be to allow a culturally defined
decimal delimiter for the locale. This could be different from the
presentation decimal delimiter. There might also be more than
one decimal delimiter, so for example both numbers using comma
and period could be read correctly. This would mean that the thousands
delimiter would not be used, but that is impractical anyway - at least
using space as the thousands delimitor is impractical.

Another thing is that inputting formats are very scarcely addressed
in i18n specs like POSIX, there is no input format for numbers or dates
for example.

keld