OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] NUMBERTEXT as well as / instead of BAHTTEXT


On Fri, 2007-16-02 at 15:34 +0100, Eike Rathke wrote:
> Hi David,
> 
> On Thursday, 2007-02-15 14:44:36 -0500, David A. Wheeler wrote:
> 
> > Qiang He  just sent me the following:
> > >BAHTTEXT is a MS specific formula function which only supports the number to text string in Thai, what about other language? Can we have a NUMBERTEXT instead of BAHTTEXT?
> > >My draft proposal:
> > >NUMBERTEXT(Language_Type type, Number val)
> > >Returns the translated text string of the number value, with a suffix specified by the type. For example, NUMBERTEXT("en-US", 1024) returns "one thousand and twenty-four dollars".
> > >type: the language type of the translation result, for example, "en-US" or "zh-CH".
> > >val : the number
> > 
> > I very much like the idea of a general-purpose function.  However, I understand that Thai users are familiar with their BAHTTEXT function, and it might ease transition if we kept that function too.
> > 
> > Instead, I propose that we have BOTH a special-purpose BAHTTEXT (to smooth transition) and a general-purpose NUMBERTEXT().
> 
> As I said earlier, defining a general purpose NUMBERTEXT would be
> a nightmare. It's quite easy for English, but just if you take different
> native numerals into account not that easy for Chinese and complicated
> for Korean, two parameters to that function already wouldn't be
> sufficient for those. For most languages the spell-out rules probably
> are unknown. So no, let's refrain from that for now, and include
> BAHTTEXT for interoperability.
> 
> > * I'd change the order, (Value, then Language_type).  Then you can make the language_type optional, with some plausible default.  The default I'd suggest would be "current locale language"; that way you could easily create spreadsheets that show written text, but the language of that text is under control of the end-user.
> 
> Actually for the purpose of displaying text, number formats are the way
> to go. How much sense do spreadsheet functions make that change their
> result depending on the locale they run in? It's the same wrong path
> that functions like DOLLAR and TEXT took.
> 
> > * In English, I believe officially you're not suppose to say "and" except between the integer and the fraction, though it's certainly a common practice. So I believe that 1024 should technically be "One thousand twenty-four".
> 
> See? Here we start already with the subtle differences. And that's for
> your native language. Same in German speech, you may include the "and"
> or you may omit it, but I'm quite sure there are some official banking
> rules that say how to write it on a cheque..
> 

If we don't have a generic NUMBERTEXT function (and I follow your
argument of this being very difficult to specify) I don't think we
should have a BAHTTEXT function either. Virtually all arguments you make
also apply to a potential plethora of individual functions and I don't
see how Thai is in any way special.

Andreas


-- 
"Liberty consists less in acting according to
one's own pleasure, than in not being subject 
to the will and pleasure of other people. It 
consists also in our not subjecting the wills 
of other people to our own."  Rousseau


Prof. Dr. Andreas J. Guelzow
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]