Posted on
of 2
/ 2
  • 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

    • 3FA77EA9-A161-4E49-BB28-A38085EF595E.jpeg
  • @allObjects
    de_CH : Switzerland
    fr_CH : Switzerland
    it_CH : Switzerland
    wae_CH : Switzerland

  • 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:

    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?


    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:­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)

    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.

    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:­c/­localization-guide/en/latest/guide/local­es/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:

    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:

    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,Oc­t,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':

    abday: "Sun,Mon,Tue,Wed,Thu,Fri,Sat",
    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­344392/

  • it’s available now, check this.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview


Posted by Avatar for MaBe @MaBe