From ALB@immedia.ca Tue Jun 17 10:20:00 1994
Received: from Clouso.CRIM.CA by dkuug.dk with SMTP id AA02686
  (5.65c8/IDA-1.4.4j for <i18n@dkuug.dk>); Fri, 17 Jun 1994 17:14:53 +0200
Received: from immedia.ca by clouso.crim.ca (4.1/SMI-4.1)
	id AA11537; Fri, 17 Jun 94 11:14:30 EDT
Return-Path: <ALB@immedia.ca>
Received: by immedia.ca (3.2/2.D)
        id AA5433; 17 Jun 94 15:20:37 -0500
Date: 17 Jun 94 15:20:00 -0500
From: ALB@immedia.ca
Message-Id: <199406171520.AA5433@immedia.ca>
To: bealle@torolab6.vnet.ibm.com, cpwg-mail@revcan.ca, paref@vm1.ulaval.ca,
        umavs@torolab6.vnet.ibm.com
Cc: i18n@dkuug.dk, sc22wg20@dkuug.dk, tc304@dkuug.dk
Subject: Re: (TC304.188) Decimal delimiter: presentation params should not fo
X-Charset: ASCII
X-Char-Esc: 29

----------
Keld suggestion is well intended, but it would not solve the problem of ease of
switching from language to language.  Why having to specify a parameter when the
function is the same for everybody on input?  When you input, you input.  If it
is to be fed back on a screen, it is a presentation matter and then you show the
character specified in the LOCALE and even the thousand (or chunck) separator.

For input you should use a function (you press a function key), not a character
(not a character key), to indicate the system you want to delimit the integer
from the residual, fractionary part of the whole number.  It should even not
generate a control character (at least not necessarily)...

Alain

Message original:
==============================================================================
         A:
            RNET (ALB@IMMEDIA.CA, BEALLE@TOROLAB6.VNET.IBM.COM, CPWG-MAIL@REVCAN.CA,),
            RNET (PAREF@VM1.ULAVAL.CA, UMAVS@TOROLAB6.VNET.IBM.COM), ALB
        CC: RNET (I18N@DKUUG.DK, SC22WG20@DKUUG.DK, TC304@DKUUG.DK)
        De: RNET (keld@dkuug.dk)
     Objet: Re: (TC304.188) Decimal delimiter: presentation params should not fo
      Date: ven 17 jui 94
     Heure: 05:42 TU
      Type: Mail
 Livraison: Reguliere
==============================================================================
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