Date().toDateString()

I guess one nice option with the app approach is there's actually no requirement to have a settings file if it wasn't needed. The app could just write the relevant functions into the locale file - eg rather than checking decimal_point, the number formatter is either just n=>n.toString() or n=>n.toString().replace(".",",").

yes, just something nicer than this locale picker

1 Attachment

Just fixed an issue for this at https://github.com/espruino/BangleApps/issues/105

@allObjects
de_CH : Switzerland
fr_CH : Switzerland
it_CH : Switzerland
wae_CH : Switzerland

Lots of updates here: https://github.com/espruino/BangleApps/issues/105

Just added 18 locales. Would be great if this is checked be native speakers.

Mon 2020.03.02

While not actively involved/engaged with Bangle and this thread as I have only been observing from a distance, Thank You @MaBe for the effort fleshing out the locales object.

'Would be great if this is checked be native speakers'

Wasn't sure if suggestions were meant to be listed here, sent as a PM, or posted at GitHub, So, as the question is asked here . . . .

Not sure if this was just a typo, as it mimics the GB example, for USA we typically use only 'km' for kilometer adopting your Deutsche 'de_DE' or International format:

"en_US"
distance: { 0: "mi", 1: "kmi" },
   change to
distance: { 0: "mi", 1: "km" },

Q: Is the default, element 0 or element 1  ?

If the speed designator is considered the parent, then the distance element 0 would be correct if the answer to the question above is true. Is the display of the speed designator dependent on the default distance label?

Reference

"en_US"
speed: "mph",
distance: { 0: "mi", 1: "kmi" },

I also had an observation with some of the case labels.

Wasn't sure of the specific reference used, so grabbed the first Google response:

https://github.com/abritinthebay/datejs/wiki/Format-Specifiers

Have always had a struggle with 'M' and 'm' as hh:mm:ss looks okay, but MM-dd-yy just doesn't feel right. I'm sure there was some frustration on your end also.

This might be considered a personal preference, but maybe there was a programming reason to use upper case?: (also note the 'M' and 'm' conflict here also)

"en_US"
timePattern: { 0: "HH:MM:SS ", 1: "HH:MM" },
   my preference
timePattern: { 0: "hh:mm:ss ", 1: "hh:mm" },

This one is a little tougher, my preference is for a 'yy' format, but banks, C.C. companies and our Government insist on 'yyyy' So, there isn't an easy way to incorporate both, just yet.

"en_US"
datePattern: { 0: "", 1: "M/d/yy" },
   visually intuitive
datePattern: { 0: "", 1: "mm/dd/yy" },

EDIT: Who is the controlling body for these locales? There are some items there that are not common here in the mid-west, specifically the date format as above:
https://lh.2xlibre.net/locale/en_US/glibc/
http://docs.translatehouse.org/projects/localization-guide/en/latest/guide/locales/glibc.html

Would be interesting to get feedback from other areas of the USA - a few known

West Coast @allObjects
MidWest @Robin
East Coast @DrAzzy
South @DamianMontero

If 'M' is required for the Month to avoid the 'minute' time conflict, then we'll have to accept:

"en_US"
datePattern: { 0: "", 1: "M/d/yy" },
   change to
datePattern: { 0: "", 1: "MM/dd/yyyy" },
   or my preference, both preferred however
datePattern: { 0: "", 1: "MM/dd/yy" },

Tougher yet, as I'm sure this is the desire to have an all three alpha character solution, but for the month of September, Sept is more frequently used:

"en_US"
abmonth: "Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec",
   may a four character month be allowed?
abmonth: "Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sept,Oct,Nov,Dec",

Finally, either Thu or Thr of these are commonly acceptable, although I prefer 'Thr' to avoid the 'u' in 'Thu' being confused with 'Tue':

"en_US"
abday: "Sun,Mon,Tue,Wed,Thu,Fri,Sat",
   either
abday: "Sun,Mon,Tue,Wed,Thr,Fri,Sat",

The rest of the 'en_US' locale looks   ok, Ok, okay, Okay !!    ;-)

Thanks @Robin,

this exactly what helps to make this a great locale app.

Finally, either Thu or Thr of these are commonly acceptable
may a four character month be allowed?

I like to followed en_US definition which is standard and keep it like that.

The goal is to find an internal definition set to have a standard and short form for date including time, so something like this mapping would work. At the moment it is a mix of Javascript and Unix.

Wed 2020.03.04

My concern post #22 about code bloat while adding additional locales was answered today in a separate thread: (individual locale parsed and uploaded to Bangle - entire locales object remains on server)

See post #6 and #7 for explanation

Iterate over array of objects
http://forum.espruino.com/conversations/344392/

it’s available now, check this.