github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-05 22:52:20 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #894] [Feature] Option to use both decimal period and decimal comma to input amounts #7284

New Issue
Closed
opened 2026-04-10 17:02:27 -05:00 by GiteaMirror · 10 comments
GiteaMirror commented 2026-04-10 17:02:27 -05:00
Owner
Copy Link

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?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

My country uses 1 000,00 as 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.45 into Actual and forget to change the period into a command, which happens very often, it gets turned into 12345,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,00 format, a period cannot be mistaken for a thousands separator, so it might be fine if the 1 000,00 format 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 .5 and 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

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? - [X] I have searched and found no existing issue ### 💻 - [X] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? My country uses `1 000,00` as 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.45` into Actual and forget to change the period into a command, which happens very often, it gets turned into `12345,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,00` format, a period cannot be mistaken for a thousands separator, so it might be fine if the `1 000,00` format 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 `.5` and 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_
GiteaMirror added the feature label 2026-04-10 17:02:27 -05:00
GiteaMirror commented 2026-04-10 17:02:28 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Apr 13, 2023):

I don’t think there are any languages where 1,00, 1,0, 1.00, or 1.0 represent integers (for example, many South Asian languages represent large numbers as 1,00,00,000 but 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.

<!-- gh-comment-id:1506913073 --> @j-f1 commented on GitHub (Apr 13, 2023): I don’t think there are any languages where `1,00`, `1,0`, `1.00`, or `1.0` represent integers (for example, many South Asian languages represent large numbers as `1,00,00,000` but 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.75<sup>9</sup>/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.
GiteaMirror commented 2026-04-10 17:02:29 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:1507900044 --> @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.
GiteaMirror commented 2026-04-10 17:02:29 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Apr 14, 2023):

If you want to open a PR that would be much appreciated!

<!-- gh-comment-id:1508627545 --> @j-f1 commented on GitHub (Apr 14, 2023): If you want to open a PR that would be much appreciated!
GiteaMirror commented 2026-04-10 17:02:30 -05:00
Author
Owner
Copy Link

@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.ts and 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.

<!-- gh-comment-id:1518645917 --> @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.ts` and 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.
GiteaMirror commented 2026-04-10 17:02:30 -05:00
Author
Owner
Copy Link

@chylex commented on GitHub (Apr 22, 2023):

maybe number input could always be agnostic about periods or commas?

I made it fully agnostic regardless of thousand separator and I find it a little weird when I can input 1.234.56 and it gets converted to 1 234,56. Inputting 1.234.56 or 1,234,56 is (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 in arithmetic.tests.ts don't cover any of these situations.

<!-- gh-comment-id:1518664057 --> @chylex commented on GitHub (Apr 22, 2023): > maybe number input could always be agnostic about periods or commas? I made it fully agnostic regardless of thousand separator and I find it a little weird when I can input `1.234.56` and it gets converted to `1 234,56`. Inputting `1.234.56` or `1,234,56` is (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 in `arithmetic.tests.ts` don't cover any of these situations.
GiteaMirror commented 2026-04-10 17:02:31 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Apr 25, 2023):

I made it fully agnostic regardless of thousand separator and I find it a little weird when I can input 1.234.56 and it gets converted to 1 234,56. Inputting 1.234.56 or 1,234,56 is (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 in arithmetic.tests.ts don't cover any of these situations.

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.

<!-- gh-comment-id:1522374621 --> @j-f1 commented on GitHub (Apr 25, 2023): > I made it fully agnostic regardless of thousand separator and I find it a little weird when I can input `1.234.56` and it gets converted to `1 234,56`. Inputting `1.234.56` or `1,234,56` is (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 in `arithmetic.tests.ts` don't cover any of these situations. 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.
GiteaMirror commented 2026-04-10 17:02:31 -05:00
Author
Owner
Copy Link

@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 👍!

<!-- gh-comment-id:1530111937 --> @github-actions[bot] commented on GitHub (May 1, 2023): :sparkles: Thanks for sharing your idea! :sparkles: 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 👍!
GiteaMirror commented 2026-04-10 17:02:31 -05:00
Author
Owner
Copy Link

@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

<!-- gh-comment-id:2227358181 --> @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
GiteaMirror commented 2026-04-10 17:02:32 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2227402234 --> @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.
GiteaMirror commented 2026-04-10 17:02:32 -05:00
Author
Owner
Copy Link

@chylex commented on GitHub (Nov 23, 2024):

Been using the latest version for a while, #2672 has fixed the problem.

<!-- gh-comment-id:2495509461 --> @chylex commented on GitHub (Nov 23, 2024): Been using the latest version for a while, #2672 has fixed the problem.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#7284
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?