some locale ideas

ideas.md

<script>
  var suchiConfig = suchiConfig || [];
  
  // EACH OF THE BELOW IS A SUCHI CONFIG... I JUST REMOVED THE NOISE

  // Move related configs into their relevant objects
  var exampleA = {
    "prompt": {
      "id": "notice",
      //... etc ...
    }
  }
  
  // pass useful data to the lag fn... sometimes it will be undefined, that sucks,
  // but it's a nice pattern... it could be an argument with named props too?
  var exampleB = {
    "prompt": {
      "id": "notice"
    },
    onlagging: function(messages, prompt_el) {
      //  If I have i18n/i10n in a server environment like php or jsp or something
      //  I can take care of it most efficiently and accurately here
    }
  }
  
  
  // Allow them to provide some messages manually... If you don't have a server environment
  // this could be useful... I have most of this implemented in my fork:
  // It looks at the navigator.language first, then falls back to navigator.userLanguage, 
  // then back to navigator.browserLangauge as IE is f*cked 
  // https://developer.mozilla.org/en-US/docs/DOM/window.navigator.language 
  // To resolve the message, it looks for your language.  If it doesn't find it and it has a "-" (as in en-uk)
  // it looks up a level (for "en") and if that is not found, it considers your defaults (we can add a base default too)
  var exampleB = {
    "prompt": {
      "id": "notice",
      "defaultLocales": ['en-uk']
      "messages": {
        "en-uk": "Yadda yadda yadda.",
        "en-us": "Yadda yadda yadda.",
        "en": "Your browser sucks!!",
        "es":  "Su navegador chupa"
      }
    }
  }
  
  
  // allow me to specify where messages can be retrieved by uri with a server side mechanism
  // which can consider my accept headers (most optimal and simply returns the actual text/fragment)
  var exampleB = {
    "prompt": {
      "id": "notice",
      "messages": "/path/to/"
    }
  }
  
  
  // auto load suchi prompts... not entirely sure how we do this well.  Seems the easiest thing is to 
  // ensure a file for every locale and template the path?
  var exampleB = {
    "prompt": {
      "id": "notice",
      "messages": true
    }
  }
  
  
  
  
  
</script>

I don't think we need to pass the prompt_el to onlagging since if you have the ID you can jsut getElementById() (assuming it's in the document at the point onlagging is called). Anyhow, I think the property bag is a better design. Also, won't messages be keyed by a message ID and then values? Or perhaps the locale keys into a an object for different messages; e.g.:

  var exampleB = {
    "prompt": {
      "id": "notice",
      "defaultLocales": ['en-uk']
      "messages": {
        "en-uk": { "main": "Yadda yadda yadda.", ... },
        ...
      }
    }
  }

ISTM that we should also look at the upcoming JS i18n API for inspiration for how to do this.

In terms of making sure we load default messages, I think the right thing to do is to have a build script that generates localized suchi.js builds and let people pick from those to start with. Saves runtime complexity.

You are probably right about passing the element to onlagging..

The code in my fork should support your example i think and does resolution for messages (laid out judt like this) based on the approach described above which, according to my understanding at least is proper, but could mean you are sending a pretty bulky object and can still be wrong since in laggards we care most about the only accurate easy is via headers. Some tests show that docs that say newer browsers match headers isn't strictly true - iirc chrome latest actually only reports my first pref, but i think it is fine since we don't care about those browsers and it should yield a rational message if not ideal in most cases.

I18n that is published has mostly to do with formatting numbers, currency, date - i see nothing in it to deal with loading bundles or their format... I would be very very happy to be shown otherwise because i was super excited when it passed.

yeah, I don't think there's any bundle support now that I read it again. I think it dropped out as a result of some ambiguities about encoding and indexing.

Looks like we should use real RFC 5646 indexes into the messages list: http://tools.ietf.org/html/rfc5646