Allow users to configure their locale and provide a default date format based on locale

[thelooter]

Currently, dates are presented as mm/dd/yyyy.
This is not intuitive for many people, and has lead to multiple wrong entries for me.
Having the ability to configure how you want the date to be presented would be really helpful

[claudey]

This is an interesting problem I may want to solve.

[thelooter]

I probably should have mentioned that before, but I would to use dd/mm/yyy notation

[zachgoll]

I think @vsme had a good start to this in #889. While we cannot accept bulk translations right now, I think this would be a good opportunity for us to configure the ability for users to set their preferred locale.

Since date formats are set once for locale, this would be a small enough scope for us to introduce without adding much overhead.

The requirements should probably be something like:

• User should be able to set their preferred date format, and app respects this setting
• User should be able to set their preferred language (disable for now, but we could have a placeholder in the UI with a "coming soon")

I think we'll want to set the locale via the strategy outlined here:

https://edgeguides.rubyonrails.org/i18n.html#setting-the-locale-from-user-preferences

@justinfar do we have some designs for this that we could post on this issue?

[justinfar]

On it!

[justinfar]

Just added a page in the community file

Here's how it's looking:

I've basically just added a Soon tag (that we use within the Security page) within the language field and added the Date format field with 5 of the most common date formats.

[zachgoll]

@justinfar looks good to me!

This issue is up for grabs for anyone who wants to tackle it. Otherwise I'll circle back and knock it out after some of the investment portfolio work I'm doing.

[thelooter]

Another idea would be still activating the locale selection with a note next to it stating that it only applies to dates for now. This would already put the data in a model that can easily be applied to other things. That way you could gradually add more places to use it, like the date or the default suggested Currency

But i dont know enough about the codebase to judge if this is a viable solution

[MagnusHJensen]

I could be very interested in trying to implement the date format selection and persisting it, as a first issue in this repo!

If anyone else would like to do so as well, feel free since I'm not well versed in ruby, so it'll most likely take some time for me, and I respect others being faster :D

[MagnusHJensen]

I've being looking a tiny bit into this.

I can see with translations (locales) this should maybe be doable, where you can provide a format that works for that specific locale, so it's hard to if you don't have other languages yet. (Could of course add it to the english version, and then it's set up for any other locales)

If going for the dropdown with options no matter what locale you choose, then there needs to be a list of pre-defined formats (Maybe the options currently present in figma?)

It then comes down to two other things:

• Postgres stores dates (not datetimes), in a YYYY-MM-DD format, should this be kept to avoid confusion, and only converted on read?
• Date inputs in the frontend (native html elements) automatically adjust the format to the machine viewing the application, so those can not respect the preferred date format set by the user.

I can also see in the transaction lists, the date is already formatted nicely.

I can though see there is places where the date string is used as is, like here:

I'm assuming it's the last case where this really have an effect?

[zachgoll]

@MagnusHJensen you're more than welcome to give this one a shot!

To answer some of your questions:

Postgres stores dates (not datetimes), in a YYYY-MM-DD format, should this be kept to avoid confusion, and only converted on read?

Correct, no changes will be made to the data storage format. This is 100% a read concern.

Date inputs in the frontend (native html elements) automatically adjust the format to the machine viewing the application, so those can not respect the preferred date format set by the user.

Good point here. For the time being, it's okay if input formats don't respect the user's preferred date format. Long term, we will likely introduce a custom Stimulus powered date-picker to handle subtleties like this along with locales that browser native datepickers don't support very well.

I'm assuming it's the last case where this really have an effect?

Yep, and also for setting default formats for data imports.

[imist]

Any thoughts on localize currency format too?
In Sweden for instance our currency symbol "kr" is AFTER the value rather than before as for $. In v0.1.0-alpha.11 I get "kr123,45" instead of "123,45 kr" which is standard. Not sure if Rubys Money::Formatter class is used in Maybe but there is an option for symbol_position. See https://www.rubydoc.info/gems/money/Money/Formatter for more info.

[zachgoll]

@imist the UI should be localizing currencies already. If you're not seeing that, would you mind sharing a screenshot of where it is incorrect so we can fix it?

[imist]

So, I have swedish format selected in Prefs...

... but it shows "kr" BEFORE the value which is not the standard for Sweden.

It should be "0,00 kr" instead of "kr0,00".
And that's where I think symbol_position in Rubys Money::Formatter class could be of help.

I suspect this formatting issue is a potential problem for more currencies/countries than Sweden. And keeping track of how the symbol should be positioned for each currency could be a PITB unless you have a library that supports it.

Anyway, here's how to move the symbol with the Money class:

Money.new(10000, "USD").format(symbol_position: :before) #=> "$100.00"
Money.new(10000, "USD").format(symbol_position: :after)  #=> "100.00 $"

[zachgoll]

@imist got it, thanks for the detail here! Just created an issue for this:

#1019