Set Locale per document or on a transform element

As a user in Denmark, I have set my locale to my current country.

But just had to make a transform which took a date (2024-10-03) and and needed to transform it to a written english date (3. October 2024).
If I did not change locale for the whole app, I would get (3. oktober 2024).

So it would be nice to be able to set/override locale either per Easy Data Transform document or maybe on individual transform elements. Like the DateTime Format.

@jimmyhartington
Possibly it is something that could be overridden:

  • at the document level
    or
  • for DateTime format and Num format transforms
    or
  • both

I will have a think about it.

1 Like

Same here.
Locale is set to English/Canada, supported date format is added “MMM d,yyyy” and a date like “Dec 5, 2024” still does not process.
Technically, the only issues should be with ddd, dddd, MMM and MMMM since those are language specific. So it may work to just completely ignore locale and only work with the language element.?

Apparently the English/Canadian locale expects a 3 character month with a dot on the end:

Jan.
Feb.

Dec.

It then converts fine.

canadian-date.transform (2.2 KB)

I think the best option would be for DateTime Format to default to the locale in Preferences, but to have the option to choose a different locale for Format from or Format to.

1 Like

Interesting. Unfortunately I seem to be getting the datafile in US format :pensive:

Yes please.

1 Like

Coming soon…

2 Likes

I like it.
But a comment to the German example, if with the „German“ setting a default for the „Format to“ field is set, it should be different for Germany:

dd. MMM yyyy (01. März 2025 or 31. Okt. 2025) would be o.k for the long format. The Blanks between the blocks are intended.

dd.MM.yyyy (01.03.2025 or 31.10.2025) is the typical German notation for the short form.

We wouldn‘t use a format as shown in your result, at least I have never seen it.

Ok, thanks. I will amend the example.

@Admin

If it is possible, that when you load a transform file, which is not same as your current locale, it currently prompts to change locale, and if you accept to change, it changes for all future new transforms as well. So can it be change for only that session? and not become as new default locale.

I usually have this issue, when I am trying to help people on forum and load their transforms, and switch to the locale of the transform, to see the data as it is, I then have to remember to switch back to my locale, once I am done with the solution.

I’m not sure how that would work, without annoying popups every time you load a .transform.

What might be better is to switch the locale from per app to per .transform. But that is a significant change and we would probably do it at a major release, if we do it.

Until then, we could perhaps show the locale in the status bar, as a reminder.

It is doing that already, it does popup every time I open a transform which is not same as my default locale set, it gives me in that pop to change or not and if I accept to open it to locale of the transform file, it sets my default locale to this new transform file locale, which it should not do.

This what I was asking, that if I open a transform file which has different locale then my default and I choose to accept the locale of the transform file from the current way by accepting from the popup, it should not change my default locale and have me work in the locale of the transform file without changing my default locale permanently to this new locale from transform file.

1 Like

I agree with @Anonymous. The default should not be affected by the popup, only this transform instance. It is useful to have the pop-up warning and option of course, but that should be local to the instance, not a general settings change.

I have this issue for every case of a transform I load from almost any other contributor. Usually I keep my own locale and hope it still works.

I understand. And the proper way to do this is to store the locale per document, which is not a minor change.

Until we have time to address this properly, I have added a reminder in the status bar:

2 Likes

By the way, I think what we are discussing here might not impact the majority of the users. So the new suggestion is a good step forward. But the complex one discussed now is from my perspective less important than other topics, like graphical visualization, etc. on the wishlist. Just my thought …

Also coming soon:

You can try the improvements to DateTime Format and Num Format transforms here:

Windows installer: https://www.easydatatransform.com/downloads/EasyDataTransform_2_6_1_snapshot_4.exe
Windows zip: https://www.easydatatransform.com/downloads/EasyDataTransform_Windows_2_6_1_snapshot_4.zip
Mac DMG: https://www.easydatatransform.com/downloads/EasyDataTransform_2_6_1_snapshot_4.dmg

Let us know if you have any feedback.

Hi Andy,

I had a look to the new format possibilities. First I identified that the Format to suggestion is not dependent on the choice of the Locale to selection. That thought was the main reason of my comment above.

I get the second selection possibilities for e.g. German

or French

But I wonder for the selection possibilities for English, e.g. the marked ones. I’m not aware that these countries (there might be more) have English as official language which might/can have own “dialects”. Do I miss something?

I’m not sure I understand. Are you suggesting that Format to should change as you change Locale to?