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


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..

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.


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