You are reading a single comment by @MaBe and its replies. Click here to read the full conversation.
  • 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/glib­c/
    http://docs.translatehouse.org/projects/­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:

    "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,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':

    "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 !!    ;-)

About

Avatar for MaBe @MaBe started