Server: Dedicated locale/region option

[georgehrke]

There should be a dedicated option for choosing the locale independent from the language.

There is a common use case, that people want to use software in english, but they don't want MM/DD/YYYY or a weekstart on Monday.

In iOS you can just choose a different language and locale:

cc @jancborchardt

[jancborchardt]

Yes, and that region format should be used by the Calendar, instead of having its own settings. :)

[georgehrke]

The calendar uses the language at the moment 🙈
We already ditched the checkbox for 12/24 and start of week for good.

[jancborchardt]

Ah right, awesome! :)

[georgehrke]

@jancborchardt What are your requirements for this feature? :)

What is the region dropdown going to look like?
A list of all countries?

[adsworth]

For reference this is what the dialog looks like in GNOME.

and both are basically a list of a locales available on the system.

[georgehrke]

moment.locales() gives a list of all available locales in moment.js

["en", "af", "ar-ly", "ar-ma", "ar-sa", "ar-tn", "ar", "az", "be", "bg", "bn",  ...]

We just need to map the array elements:

en => United States (english)
de => Germany (german)
de-at => Austria (german)

We probably want to filter the list though. It contains as much as 107 elements.

[jancborchardt]

Exactly, it should be directly together with the language dropdown, and default to the same as the language.

[skjnldsv]

Youhou!! :D
Also: why not have an option for h24 and monday? I think it would be easier to understand that choosing a locale (since even around me people uses different way to say the date/time)

[georgehrke]

@adsworth Do you want to work on this? :)

[adsworth]

Yeah, I would like to work on this. I'll need some help pointers concerning Javascript and how it all works together on the server side. But I guess I can get that in the IC dev channel.

Also I can't really give at time line. If that's OK then I'll assign it to me.

[ralin3]

Can someone please confirm or deny whether this will end up being user selectable "somehow"?
NC12 lost en_GB, so I have no option to have english language, 24h clock and weekday starting on monday.

The comment made by @jancborchardt makes me think that this will not be a user selectable option, rather force users to select a language that has the needed options, instead of providing sane defaults (detected based on users language) which can be overridden.

[georgehrke]

@ralin3 Every user will have a new region input below the language input in the personal settings.

[founderio]

Will there be an option for ISO dates? (2017-01-01 ...)

Right now, I have the option of using US format (for me, German, that is just a weird format.)
The other language that I understand is German - with weeks beginning on Monday and Clock in 24h format. But I dislike our date format. (And I do not use German software translation.. Too many incomplete or weird translations out there...)

I guess there will always be "the odd person" who is not keen on their own country's date formatting.

For reference, Jira allows overriding the date formats to a completely custom one:

[georgehrke]

As far as I can tell there is no way to tell moment.js to use ISO as a locale, so probably not.

But I dislike our date format.

Out of curiosity, what do you dislike about it?

For reference, Jira allows overriding the date formats to a completely custom one:

I'm sorry, but that's a completely overkill. It might benefit a small share of users, but vastly increases code complexity and clutters the interface with even more inputs. That will have a negative result on general user experience.

[georgehrke]

@jancborchardt btw, if a user selected the language english but the region german, should day and month names appear in german or english?

[founderio]

Out of curiosity, what do you dislike about it?

It has the wrong ordering. When using yyyy-mm-dd you can use alphanumeric sorting and have ascending dates. The German format defines dd.mm.yyyy. Personal preference I guess.

As far as I can tell there is no way to tell moment.js to use ISO as a locale, so probably not.

Is there a locale called en_DK? On Linux this is sometimes used to have ISO dates in English language...

I'm sorry, but that's a completely overkill. [...]

Fair point. But ISO dates should be an option somehow, no? It is an international standard after all.

[georgehrke]

Is there a locale called en_DK?

I don't think so. You can see the list at the bottom of https://momentjs.com/

But ISO dates should be an option somehow, no?

Yes, it would definitely be nice to have. We have to see how easy it is to get an iso locale in moment.js.

It actually offers you to define your own locales, so that might be fairly easy after all.
We have to see.

[pixelipo]

@georgehrke region sets regional preferences, such as date, time and currency formats.

I agree that JIRA override is a huge overkill. It makes sense in JIRA, only because you might want to import from/export to a weirdly formatted 3rd party service

[nickvergessen]

if a user selected the language english but the region german, should day and month names appear in german or english?

language is language, region is format

[pixelipo]

@founderio try en_IE - if I'm not mistaken, it has "European" date format

[founderio]

@pixelipo Well, I would try, but that won't work with a stable build of Nextcloud, would it?
(Which is how I turned up here...) Is there some way to make it believe it has en_IE? or even en_UK for that matter, and just use the same translation as en_US?

[Keridos]

I support this as well. I like my nextcloud in english, but since I cannot use en_GB my nextcloud will always fall back to 12h time format in English (US).

[georgehrke]

@Keridos Please use Github Reactions when you can't add anything new to the discussion. Thx :)

[bahbarnett]

OK -- I need to chime in here. I do hope this adds to the discussion while development commences / continues.

Primarily to say, the hell? ;P Most coders are certainly not about conforming. About following, or adhering to rigid social structures.

Yet, here we have people advocating that people in an arbitrarily chosen group (IE, 'locale'), have specific language, time, date, and spelling preferences due to that designation. And 'outliers' are 'weird'.

I see concerns about code complexity. And concerns about UX.

A person can live in Canada, prefer US spelling (not Canadian), prefer French 24hr time, European date formats, and that's not even remotely unusual.

So, what I'd say is -- expect that the reality is, the user is a locale comprised of 1 entity.

Under Linux, I don't know how to retain en_ca, and yet set 24 hour time and different date formats system wide... so, I don't see how/if the browser could snag that.

[pixelipo]

@bahbarnett the fact that you don't know how to do something, doesn't mean it can't be done - here's how you can set every single aspect of locale separately in linux.

What you are looking for as default locale is en_IE, because it is 24h time and European date format. You could also use German locale for that matter, since according to :arrow_double_up: locale settings would be independent from language settings.

Regarding conformity, this is more of an UX issue than a coder one. An application strives to "please" most of its (potential) userbase, definitely not all. Outliers can be accommodated if there is a valid case for that - on one hand you might get a handful of new users, on the other, you get more complicated UI and a (perhaps larger) handful of unhappy/confused users.

[bahbarnett]

en_IE has US spelling? Not en_UK?

I appreciate the suggestion, but finding a specific answer to my specific locale needs won't help. That only helps me, not other users with differing locale needs.

And, while I also do appreciate your info on setting system wide locale settings, often one might want not to set settings for ALL users, and instead set settings for specific users. Or, involve the root user.

And, even with the "but..but.. users can..", you still have the situation where users might have differing needs for differing pieces of software. A locale for work (a word processor), a collaboration tool (again, because of shared requirements for work), and the list goes on.

The idea that locales are system wide, or user wide is completely debunked. If you want to quote UX theory, then you must also look at reality. And wonder why so many applications out there provide for this.

And on the UX issue? Keep in mind that current UX theory was crafted by people creating code in the late 90s and early noughts. People using computers in the 90s and early noughts, were quite often NEW computer users. Or, new to computing.

Grandma was buying a computer. Uncle Jim. Tom across the street. Peple in their 40s, 50s, and 60s which had NEVER even touched a computer before, bought them. As well as mobile devices.

Yet, soon enough we'll be in a situation where realistically no one is a 'new' computer user. People will have merely grown up with computers, with few being alive that have not touched such a device in their youth.

To such users, things like "settings' and 'looking at them" aren't as confusing as what 90s and 00s UX theory supposed.

Succinctly put, current UX design theory is decades out of date... based upon a userbase that no longer exists as it did when it was crafted.

I'm not suggesting you want to add 1000 options. Yet assuming that people will get confused, be scared, and leave if you have a tab for 'time settings' with a few options on it is ... excessive.

Part of UX in such cases is, are the terms confusing. Something that boggles the user's mind.

"24hr" and "12hr" time format, and 'date' format are certainly not such a thing.

Anyhow, I'm sure we don't want this to turn into a larger discussion here. So, I'll listen to your reply (if any) and leave it at that. Unless there is a query for a specific question / response.

Thanks

[pixelipo]

spelling is a language setting, not a regional one. Thanks for reading my previous post carefully, @bahbarnett

[bahbarnett]

Well, if your response is going to be like this, yes -- I'll reply.

Where do you infer that I did not read, when I asked a question specifically about what you said? What in my post indicates, after my two questions, that I disregarded your statement completely?

If you disagree with some of what I said -- fine, no issue. But it seems you're the one that is perhaps not reading, for your only reply was to my first two sentences.

[ralin3]

This whole discussion is out of topic, and haven't been on topic for quite some time.

Users want to choose the regional settings and the display settings, nobody wants to code it and have not been willing to do it for quite some time.

NC10 had this functionality, NC11 forced you to use en_GB to get it (and I believe there was an issue made for NC11 with milestone NC12 to fix it.) - NC12 doesn't have the option at all.

I have to use my native toungue to get the regional settings correct, but that makes the product seem half-assed since plugins are not translated, and the software is not properly translated.
Yes, I know I can help with the translation - but that isn't the point!

I can't make someone accept my translation to every plugin available, and the rest of all my software and OS is, and supports, using english as display language with different regional settings.
Heck. even the nextcloud-client supports it.

iOS allow you to change display and regional settings differently, and as far as I know - they have very strict UX-rules.

[bahbarnett]

I think part of it is the target market.

This isn't designed for corporate, or for power users. It seems to be targeted to non-power users. Certainly not with the immense lack of features in calendar and contact apps, and a strong rejection of adding features.

There's likely a large market in non-corp and non-power users for a simple, no bells and whistles product like this.

Unfortunately, there is ALSO a market in 'getting away from Google' or Zimbra and not using closed source products in corp too... and it's not being targeted here. Which is fair, I suppose -- one product can't be everything.

So, if we eye this product / codebase in that way, and understand that usability improvements will be rejected (ie because of UX), then at least we're all on the same page.

[tcitworld]

Maybe stop being out of topic and comment on https://github.com/nextcloud/server/pull/5623 would be nice ?

[MorrisJobke]

Fixed with #5623

[jkelly99]

I would also like to put my vote in for 24 h clock settings and Monday start of week without needing to change locale settings. I am in the US and work in a medical setting. We use US date format, 24 hr clock, and Monday start of week.

[dugganjl]

I would also prefer to have date, time, and start-of-week settings independent of the Locale setting.
I'd like to be able to set a 24 hour clock, yyyy-mm-dd, and Monday as start-of-week.

[telmich]

Hello! This issue seems to be closed on github, however I don't see how I can select 24h, Monday week start or iso format anywhere in nextcloud 16.0.8. Am I just blind or is it not there?

[jkelly99]

My workaround is setting my local as English(Ireland). That gets you 24 hr clock with Monday week start. Stuck with European date format, but I can live with that.

[haarp]

I don't understand what got merged here, but it's still impossible to select ISO-8601 (yyyy-mm-dd) date formats, 24h time, week starting monday, English strings in NC 19.0.4. Is there another issue that I missed?

[haarp]

Ok, I've just opened #24134 which, once fixed, should finally give us English ISO-8601.

[remram44]

Can we just have separate settings for that instead of making people use en_DK? Are we sure there is a locale that use 24h for each language that Nextcloud supports, or do we only care about English?