From ALB@immedia.ca Wed Jun 18 12:41:00 1994 Received: from clouso.crim.ca ([192.26.210.1]) by dkuug.dk with SMTP id AA03791 (5.65c8/IDA-1.4.4j for ); Sat, 18 Jun 1994 19:37:19 +0200 Received: from immedia.ca by clouso.crim.ca (4.1/SMI-4.1) id AA25369; Sat, 18 Jun 94 13:36:33 EDT Return-Path: Received: by immedia.ca (3.2/2.D) id AA30009; 18 Jun 94 17:42:41 -0500 Date: 18 Jun 94 17:41:00 -0500 From: ALB@immedia.ca Message-Id: <199406181742.AA30009@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: Decimal delimiters X-Charset: ASCII X-Char-Esc: 29 ---------- Glen says: >I disagree strongly. Function keys are not mnemonic or intuitive >and are therefore distincrtly unfriendly to inexperienced users. >One of the best things about a GUI is the lack of the need for >function keys. > >For data entry, users will want to use the separator characters >that they are familiar with, or that appear in hard copy that is >being entered. > >Having said that, I don't see why the LOCALE numeric and monetary >specifications aren't sufficient to handle input. Whether the >sparators get converted into a generic code after entry is surely >an internal implementation issue. > > /glen > >----- Begin Included Message ----- > >Date: Fri, 17 Jun 1994 16:20:00 -0400 >> From: ALB@immedia.ca > >---------- >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 This is based on a real practical problem I described but that I see, Glen, you were not confronted with. If a GUI is good in theory and is beautiful, shouldn't it suffer exceptions if it is not so elegant in practice. Function keys are indeed necessary for functions on keyboards. What about the select level 2 (traditional shift key, a now deprecated term), the tab key, the return key, the insert key, the delete key and so on. What will GUIs do to replace these? If what is necessary to operate on text is there, why wouldn't what is necessary for numbers be there? I still maintain that a function is required for that so that you don't have to change input parameters because you use different presentation features for translating for output the result of a same input function. In Canada indeed, I mean even in English Canada, I heard some scientists say they were using the SI conventions in scientific work (so a comma as a decimal delimiter) and if they use a banking software they will have to use a decimal point. Why changing input parameters for numbers even if presentation is changed? The same kind of conceptual objects, numbers, are manipulated in both cases. Furthermore, let's say you are also in Canada, and you do your billing for different countries and different currencies and currency presentation conventions, why should you bother the person that enter numbers in escudos to enter 123$45 sometimes, 123.45 some other times and 123,45 some other times (bothering will occur, as our users encounter the problem, when you're forced to adapt your input method to the output presentation characteristics of a report you will perhaps never see). No, really, I sincerely believe the problem our users have (which is a fact, not a theroretical fantasy) has only one solution: to have a function for separating fractions from integer. That fuction has no reason to be dependent upon presentation parameters, a bit like it was wise in ISO/IEC 10646 to choose coded characters for Arabic that are not dependent about the position of each character (Arabic letters have typically 4 different shape according to their placement in a word, initial, middle, ending or stand-alone, but coding does not code shape variants any more for normal applications). Now before I end, because this is a position adopted at our Canadian TG9 and that you're a Canadian, tell me if you still don't agree. If there is no internal consensus in Canada, I will present it as a personal contribution. I want to be loyal to my friends, and to the national body I represent. I will respect your opinion even if you don't agree with my further explanation. So far I maintain my personal position though. I will present your opinion to SC18/WG9 with the contribution, whether it has personal or national status, so that others can have all the light they need to form their own opinion. With my best and friendly regards. Thanks for this frank opinion. I need such opinions in advance. Not after an eventual ballot. Alain LaBont