On 30/06/2020 08:16, Justus Pendleton wrote: > On Monday, June 29, 2020 at 11:34:09 PM UTC+7, Martin Blais wrote: > > One of the things we might want to do for v3 is make it possible to > specify the locale within Beancount itself (insulating it from its > environment) and perhaps bring back the checks (simply removing the > commas works). OTOH, right now we don't support decimal commas. > Ideally we support all this in v3. > > > Handling locales is tricky. The locale is (kinda sorta) tied to the > currency. I use multiple currencies. One is USD but the other is VND > which is officially defined with "decimal commas" for thousands > separators and "comma decimals" for fraction separators. Which one > should I use in a given entry?
Individual practices may deviate from this, however in "official" locale definitions the monetary formats tied to the locale language and zone, and not to the currency. It is expected that the same construct are used consistently to represent numbers independently to the currency. There is no definition for how to represent amounts in USD, but only a definition for how to represent monetary amounts in American English, also known as the "en_US" locale. For example, the Euro is used across different locales and in many of them monetary amounts are spelled differently. > It might seem obvious -- "let the user pick one and then everything is > in that" -- and that might work if all data was user-generated. But the > reality is that much of our data comes from external sources and all of > them will generate data in their native, expected format. What is discussed here is the format accepted for amounts in the Beancount input files. Facilities for parsing external data sources are an issue that is only tangentially related. > My US bank > will export CSVs one way and my Vietnamese bank will export CSVs in > another. I'm not sure we want beancount importers and price fetchers to > have to parse the user file to lookup their locale to know what format > to emit things in. (And unless doing so was made super easy for 3rd > party authors of importers and price fetchers it seems likely that few > would bother and would simply emit "raw" numbers which would work for > 99% of users but be completely broken for others.) I don't know what you mean by "raw" numbers. The Beancount import mechanism only accepts data in decimal (as in instances of the Python decimal.Decimal class) representation, not in string representation. It is responsibility of the import modules to perform the conversion from strings to decimal. When the imported transactions or prices are serialized into Beancount ledgers a choice must be made about which format to use. It is true that Beancount does not provide any fancy or locale aware way to parse decimal numbers, but I don't think it should. Writing a naive parser is trivial and there are dedicated libraries for more fancy solutions. > Allowing individual files to have their own locale would allow us to > work around that maybe. I don't understand which problem you are trying to work-around. Different locales for different Beancount input files can be supported without too much complication (once a locale aware parser exists). However, in most cases, if a user handles different currencies at some point it will need to have transactions with legs in different currencies, and only one locale could be used for reporting, thus still having some amounts written in the "wrong" locale for the currency. It would also be very confusing: assume you have one file using en_US locale and one using fr_FR locale, it would be very hard to know what an amount like "1,000 JPY" is simply looking at it. Are these one Yen or thousands Yen? Cheers, Dan -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/7a45825a-9ac0-80eb-afd8-01ac6f1887b4%40grinta.net.
