[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NUMBERTEXT as well as / instead of BAHTTEXT
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(). I like the GENERAL idea of what Qiang He suggests, here are few mods I'd suggest: * 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. * I'd add one or more parameters so that it's not limited to money (though that's a reasonable default). AT LEAST it should a logical True/False "Add monetary units" (default true). It'd be nice if we could provide text for the integer unit (e.g. "dollars") and maybe fractional part, but I worry that would be never ending (how do you handle singular vs. plural? Dual? Zero? How many digits?). But the True/False would be easy, and make the function more flexible. * 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". There's no end to the number languages that could be supported. We should require AT LEAST one, English; it's the official language of more countries than any other language, and we already spec that for purposes of testing. I suppose we could require support for the "top ten" languages (by count of number of speakers), that's at least defensible and I believe that info is easy to get. Not very official, but here's one breezy article about that, and most importantly it includes ALL speakers (1st language or not) which I think is important: http://www.soyouwanna.com/site/toptens/languages/languages.html It depends on how you get stats. Here are top 10, Internet use: http://www.internetworldstats.com/stats7.htm Top ten for 1st language: http://www.lilithgallery.com/articles/2005/languagesoftheworld.html How large and small should be supported? I'm guessing at least down to 0.01 increments, from 0 to 999,999,999. (If further, I suggest using "small" billion==1E9. UK traditional practice is billion==1E12, but I think the UK is increasingly switching to U.S. conventions, in part because of the influence of the metric system. That's ironic, but a different issue...!) Thoughts? Overengineered? Creating new functions "from scratch" isn't ideal, but is a reasonable response to deal with an EXISTING function that is overly constrained (e.g., BAHTTEXT). Unless there are objections on the list, I think Qiang He should try to write proposed text for the function, including a specific list of languages needing support (with text in Rationale explaining why that list). I think NUMBERTEXT should be in the Large list; I suspect many apps will NOT support it. --- David A. Wheeler
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]