In the US at least it is customary to write out the amount and put it in digits. My checkbook in front of me has a form like:
Pay to the order of _________________________________________________ $ ______ _______________________________________________________________ Dollars I am expected to fill it out as: Pay to the order of _John Smith_____________________________________ $123.45 _One Hundred Twenty Three and 45 Cents----------------------------------------------__ Dollars I would never expect that second line to be "One-Two-Three and Four-Five Cents". I believe I have seen some computer-generated checks which would fill out the second line as "123.45****************" and not bother converting it to spelled-out numbers. I once made out a check for the amount "Twenty Even" and got charged $27, so the amount in English does get read, even if incorrectly. The rule is that if the number (the $123.45) and the text (the "one hundred...") disagree, the text takes precedent. On Sun, Nov 3, 2013 at 9:25 PM, Johannes Kapune <lis...@kapune.de> wrote: > Am 04.11.2013 00:48, schrieb John Ralls: > > >> On Nov 3, 2013, at 11:14 AM, Geert Janssens <janssens-ge...@telenet.be> >> wrote: >> >> On Sunday 03 November 2013 08:01:38 John Ralls wrote: >>> >>>> On Nov 3, 2013, at 2:32 AM, Geert Janssens <janssens-ge...@telenet.be> >>>> >>> wrote: >>> >>>> And that's only three languages that I know. I'm sure many other >>>>> languages have still different ways to form larger numbers. These >>>>> oddities in languages can't be covered in only with gettext as far >>>>> as I know, or you will have to add quite a lot of individual >>>>> numbers to translate. >>>>> >>>> >>>> ICU has that built in and localized: >>>> userguide.icu-project.org/formatparse/numbers >>>> But note: >>>> "ICU provides number spellout rules for several locales, but not for >>>> all of the locales that ICU supports, and not all of the predefined >>>> rule types. Also, as of release 2.6, some of the provided rules are >>>> known to be incomplete." >>>> >>>> But I see no reason to add the dependency for something that's already >>>> done via gettext. >>>> >>>> This is the part I don't understand. How can gettext handle all the >>> different number spellout rules ? >>> >> >> Sorry, I misunderstood what you meant in " These oddities in languages >> can't be covered in only with gettext as far as I know”, reading it as >> “these oddities … can be covered only with gettext…”. Quite the opposite of >> what you meant. >> >> I also failed to catch that in spite of all of the comments in >> gnc-ui-utils.c, none of the strings are actually submitted to gettext, >> which is explained with Christian’s comment about the integer_to_string >> function being untranslatable. >> >> Sigh. >> >> So we *can* do that only in English. >> >> So I guess the question is do enough non-english speakers actually need >> it? The Wikipedia article Thomas cited earlier suggests not, but perhaps >> you have more direct knowledge otherwise. >> >> With that answered, do we want to bring in ICU as a dependency to meet >> the requirement. The documentation of that class is not up to the standards >> of some others, and I wasn’t able to figure out what locales are actually >> supported. >> >> Maybe I'm wrong but for printing on checks normally you print the digits > as words: 123456,78 to > > ---one-two-three-four-five-six and seven-eight cents--- (per cent ...) or > do you really write: > > onehundredtwentythreethousandfourhundredfiftysix Dollar and seventyeight > cents? > > To make the checks save to manipulating the amount first sort of writing > seems to me is enough and it is translatable to other languages. > > Best regards > Johannes Kapune > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
