mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-15 22:54:03 -05:00
[GH-ISSUE #894] [Feature] Option to use both decimal period and decimal comma to input amounts #14583
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#14583
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chylex on GitHub (Apr 13, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/894
Verified feature request does not already exist?
💻
Pitch: what problem are you trying to solve?
My country uses
1 000,00as the currency format, but I often copy/paste amounts from applications or files where the currency format uses a decimal period.I cannot change the format globally, because then I would not be able to input anything using the numpad, which uses a decimal comma.
Since my country uses spaces for thousands separator, I'm used to decimal commas and periods being interchangeable, and in fact some programs support that (for ex. old Windows calculator, before Microsoft replaced it with the UWP version that doesn't support it and that makes the app unusable for me).
Currently if I copy/paste
123.45into Actual and forget to change the period into a command, which happens very often, it gets turned into12345,00.Describe your ideal solution to this problem
I would really appreciate an option that makes Actual accept both decimal comma and decimal period.
I'm not sure what would be the best way to implement it; with the
1 000,00format, a period cannot be mistaken for a thousands separator, so it might be fine if the1 000,00format automatically converted periods to commas, but I don't know whether that would cause issues for others.It might also be possible to automatically detect the decimal separator by the number of digits after it, but I'm also not sure whether it would be 100% unambiguous. It might require setting an exact number of decimal places somewhere, or at least prohibiting more than 2 decimal places so that you could still type
.5and have it accepted as.50.It might be best to just not try to be too smart, and have either of the two suggested behaviors be optional in the Settings.
Let me know what you think. Thanks!
Teaching and learning
No response
@j-f1 commented on GitHub (Apr 13, 2023):
I don’t think there are any languages where
1,00,1,0,1.00, or1.0represent integers (for example, many South Asian languages represent large numbers as1,00,00,000but the last value group has three digits), so maybe number input could always be agnostic about periods or commas? One downside to this could be that e.g. gas prices (which in the US are conventionally written $2.759/gallon for some reason) would be interpreted as $2,759 and not $2.76. Hopefully that would be fairly obvious when importing a CSV or pasting the value in! We could also check after imports to see if there was a mismatch in detected decimal separators and pop up a warning.@chylex commented on GitHub (Apr 14, 2023):
That makes sense. Let me know if you'd like me to PR anything, or if it's a simple enough change that a PR would not actually save you any time.
@j-f1 commented on GitHub (Apr 14, 2023):
If you want to open a PR that would be much appreciated!
@chylex commented on GitHub (Apr 22, 2023):
I'm not sure where to find the place that parses the input fields, I suspect it's somewhere in
util.tsand was trying to follow the code flow with breakpoints, but for some reason breakpoints aren't working at all. PhpStorm is connected to the debugger but breakpoints aren't firing, and Firefox's Debugger tab isn't even showing any scripts. Any tips?EDIT: Debugger works in Chromium.
@chylex commented on GitHub (Apr 22, 2023):
I made it fully agnostic regardless of thousand separator and I find it a little weird when I can input
1.234.56and it gets converted to1 234,56. Inputting1.234.56or1,234,56is (imo) an error, but I'm not sure if it's a good idea to change the parsing behavior in this case. Maybe it should only be agnostic if the user selects spaces as the thousand separator? The unit tests inarithmetic.tests.tsdon't cover any of these situations.@j-f1 commented on GitHub (Apr 25, 2023):
I think this is fine. (And feel free to add new tests). The result of entering the value is immediately visible to the user, and they can always go back and change it later if they don’t like how it’s interpreted.
@github-actions[bot] commented on GitHub (May 1, 2023):
✨ Thanks for sharing your idea! ✨
This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).
The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=is%3Aissue+label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc
Don’t forget to upvote the top comment with 👍!
@andriantoeff commented on GitHub (Jul 14, 2024):
Seeing the merge is reverted by #1144, does it make the feature request stumped or is there another progress? Would this issue be the best place to carry forward the discussion for this?
There's also similar feature request #2318 and merge #2672 (Make comma's and period interchangeable when entering figures). How does it relate to the works on this feature request? Does it solve/partially-solve this feature request?
@chylex
@chylex commented on GitHub (Jul 14, 2024):
I think my personal problem might be solved by #2672, but I haven't tested it yet. I've been using the version before the revert.
@chylex commented on GitHub (Nov 23, 2024):
Been using the latest version for a while, #2672 has fixed the problem.