Thanks for swift reply as always. Both here and at StackOverflow. Your customer service is beyond comparison.
Here are some screenshots and further explanation:
First the definition of the fields in the Update DTO and the Query DTO. I intentionally left the EndDate without locale, to see if there was any difference.
Query DTO (actually it is:
public class QueryEmployees : QueryDb<Employee>, IReturn<QueryResponse<Employee>>, IGet
and here is the Employee:
And this is from the Request headers, when clicking Edit:
The “nb” is Norwegian Bokmål, and later in the list you can see “nb-NO”, but it seems to come after “en-US”. This could be the culprit, as “nb” and “en” is probably disregarded, if it looks for those “a-B” style locales, where “en-US” comes first.
Here’s the settings in Chrome:
By moving Norwegian to the top, the one that was no. 3 in the screenshot, so both Norwegian Bokmål and Norwegian (generic one), the header changes to:
We now see “no” and “nb” comes first, but still “en-US” comes before “nb-NO”.
I can say with certainty that at least half of people in Scandinavia will be using English user interface, but want the date format in the correct order. Same with 24H clock instead of AM/PM. Perhaps also comma vs. dot as decimal separator.
Many of us feel user interface in our native language looks weird, often due wonky translations.
When I read that you’re using the browser’s native UI elements for DateTime, my experience is that this will require fighting with the browser. And we can’t do that for each user, requiring them to change their browser settings etc. (and as you can see simple fixes don’t even work). It should be possible to do from the App. Like some user setting for language, date format, number format, time format. This is what will be required of me as a developer, so I need this to be possible with SS if I’m going the Locode route. Or I’ll have to already go for custom components this early in the process with Locode (which kind of defeats the purpose I think).
Would you consider, since Locode is Vue3 driven, to use a component instead of the browser’s built-in date-picker? And perhaps for some other typically localized inputs as well? That would make Locode so much better.