On long pages (such as the guide) the header structure sometimes gets down to <h4>. With our current formatting that isn't particularly distinguished from surrounding prose.

We could perhaps tweak the headers to be more visually distinct, such as with underlines or background colors.

Hmmm... if we have a table of contents (#84) perhaps this won't be such an issue.

Hi all!
I've made an internationalization helpers for nunjucks templater, nunjucks-intl.
Nunjucks is developed by Mozilla, and it is a rich and powerful templating language for JavaScript.
If you know about Jinja in Python world or Twig in PHP/Symfony, than Nunjucks is just the same thing, but in JavaScript. It works in browser and node.js env.
Will be great, if someone could check it out and add mention to format.js site. Actually it's based on handlebars-intl at base level, but of course is adapted to nunjucks enviroment. It's covered with tests. The last thing, that my lib is missing for now — is a #intl block, due to some problems in nunjucks itself and will be fixed in future, but beside that, it is working great!
Any feedback is welcome!

We currently mention the browser support on the site's home page, and in the READMEs of each of the integration pages, but we should promote this information more since it's important, and we have a good answer — it works everywhere!

As I move towards pushing 2.0 out, it is easier for me to no longer maintain the documentation due to the complexity of hosting an ember-cli addon within a react application. I'd prefer to instead provide a link to the github wiki articles.

The method we have for loading in client-side JS files automatically is very fragile and throws errors if the file doesnt exist.

The problem exists in line 8 of yepnope-init.js. It will automatically try to load a JS file called exampleUrl which will throw an error if that JS file is not available.

I wrote an integration for generic Express support, especially for template engines that don't support their own integrations like EJS. I based it off of the handlebars and react integrations.

https://github.com/redbugz/express-intl

I would love some feedback on the approach. I've set up things a little different from some of the demo express projects. I plan to add client-side support next.

There are three main optimizations that should be done to the site's build process which is greatly optimize the number and size of the scripts loaded on the page for our Intl libraries:

• Conditionally load Intl Polyfill.
• Update Broccoli build to create a combined intl-integrations.js that bundles react-intl, handlebars-intl, and dust-intl together (deduping common deps.)
• Update Broccoli build to combine locale data into intl-locales.js that bundles Intl.js, intl-messageformat, and intl-relativeformat for all locales the site supports.

I think it's important to stress that even if you're not deploying an app into multiple locales, FormatJS is still very much helpful and relevant for English or any single locale. <-- We should add that to the site somewhere prominent.

Before we can merge the docs-site branch, we'll need to migrate the existing .md files to handlebars.

• introduction.md
• isomorphic.md
• quickstart-browser.md
• quickstart-node.md

Some of the longer pages, such as the guide and the individual integrations pages, might benefit from a table of context. This will help developers reach/reference the section of page related to their current task.

reading thru the guide makes really difficult to know what section are you reading, sub headers are almost the same size/font than regular content. maybe better delimiters for sections.

I noticed that the relative format examples that display "1,320" minutes aren't formatting the number according to the locale.

Whereas when I try to use IntlRelativeFormat directly it works fine; e.g., in French:

var rf = new IntlRelativeFormat('fr', {units: 'minute'})
rf.format(Date.now() - (1000*60*1320)); // => "il y a 1 320 minutes"

now that we have long pages, we need a way to share links to specific sections, maybe having an anchor icon or something for people clicking to anchor.

Currently the {variable, number, currency} doesn't work. A workaround is to first use Intl.NumberFormat and put those results into a variable and use a simple {variable} argument.

So, we should document that workaround.

Putting all of the site's CSS into one file is getting crazy. We need to figure out how we can split everything into separate files, but then have our PostCSS via Broccoli build process stitch everything back into one .css file.

I attempted this when I first added PostCSS, but ran into some issue and punted for the time being.

In formatjs/intl-relativeformat#26 it was brought up how being able to pass an optional now value would be useful to make IntlRelativeFormat#format() a pure function; and PR formatjs/intl-relativeformat#27 implements this new feature.

When @jlecomte wrote the functional tests for the site he had to override the Date constructor and Date.now() static method so that his tests could produce predictable values. This approach had to be taken since IntlRelativeFormat#format() always calls Date.now() to get the current value for "now". [email protected] will add a new feature to allow passing the now value and this will remove the need to hack the Date object in the site's functional tests.

I realized that we don't mention the number of languages that are supported on the home page. We should add some section for that.

You know Node.js v0.12 supports Intl object finally, but it support only English language as default. I think that it means there are cases of it doesn't works as expected on the way to fallback as follows which we are suggested.

http://formatjs.io/guide/#intljs

if (!global.Intl) {
    global.Intl = require('intl');
}

Maybe we should simply detect environments based on the version of Node.js, but I see if there are better ways of doing things. What do you think?

Incidentally, we need to update the section in our guide for server side.
http://formatjs.io/guide/#server-side

Remove defaultLocale from emberjs integration. This will remain an undocumented feature and likely be removed after 1.0.0

I thought this was handled yesterday, it's still there. Perhaps bad merge?

The website is serving static resources with ETag headers, but also setting Cache-Control max-age: 0 which forces the browser to always re-download assets instead of performing conditional GET requests.

On the French homepage:
Wrong: "Le ‎15‎ ‎avril‎ ‎2015, Annie n'a pas pris de photographies"
Shoud be: "Le ‎15‎ ‎avril‎ ‎2015, Annie n'a pas pris de photographie"

Sorry for my bad english,
Dust v1.1.1 download link not working: https://github.com/yahoo/dust-intl/releases/download/v1.1.1/dust-intl-1.1.1.tgz may be https://github.com/yahoo/dust-intl/archive/v1.1.1.tar.gz ?

I've never heard anyone say that he took "photographies", instead everybody in France says that he took "photos".

Le 14 octobre 2014, Annie n'a pas pris de photographies.
Le 14 octobre 2014, Annie n'a pas pris de photos.

Even the google query for "prendre des photographies" only returns results with "photos": https://www.google.com/search?q=prendre%20des%20photographies&gws_rd=ssl

Polymer has a way to integrate formatjs into Polymer applications. Might be good to provide this information in the list of integrations?

https://elements.polymer-project.org/elements/app-localize-behavior

https://www.polymer-project.org/1.0/toolbox/localize

We should add a composite examples of how to render a relative-time inside a message since it might not be clear to people that they can create composite structures. In order to do this, we'd need to translate the message in all our supported locales (what's in the locale switchers).

Basically this:

{name} posted {ago}

<p>
  {{formatMessage (intlGet "messages.posted")
    name=post.author 
    ago=(formatRelative post.date)}}
</p>

In all of the libs (low-level and integration) we use the plural locales, and this confuses people since their mental model is that the page is in a single locale. The reason we do this is to align with the Intl* APIs which support fallback locales.

To help make setting up the locale(s) easier for people to understand we should be explicit about the fact that a single locale is support and the most common thing people will be using.

Related: formatjs/formatjs#39

Go to https://formatjs.io/
Change Locale in dropdown to another. Then again and again. Go on. Sometimes previous translation remains and example div shows all of them:

The locale tags used by Firefox are all lower-case; e.g., en-us instead of en-US. The content negotiation process should be case-independant.

In #61 I didn't add content for the Modular, and ready to use and Runs in the browser and Node.js sections. These will be more involved since I'd like to create a diagram that shows the modules stacked up. And we need to determine the exact browser support so I can add that to the Home page as well.

The download button on emberjs integration doesn't apply to ember-intl. You would never, in normal circumstances, download the static assets since the addons should be installed using ember install:addon ember-intl or npm install --save ember-intl

I'd prefer we just target ember-cli with the exception of the custom packaging reserved mainly for this site.

Thoughts @ericf

We suggest using yepnope.js for the client side integration, but yepnope.js has been deprecated and it's no longer actively maintained.

I think we need to provide something about any good ways (like Browserify, webpack, SystemJS) for developers.

• http://formatjs.io/guides/runtime-environments/#polyfill-browsers
• http://yepnopejs.com/
• https://github.com/SlexAxton/yepnope.js
• http://browserify.org/
• http://webpack.github.io/
• https://github.com/systemjs/systemjs

In the recent refactor of the integrations pages we left off the part where we tell people how to load the locale data. This needs to be added.

Hi,
I wrote a basic integration for Riot.JS here:
https://github.com/ListnPlay/riot-intl
It's based on the React integration.
Would be great if you could check it out, and perhaps mention it on your website once it meets the standards.
Thanks!
/Avner

It might be helpful to add a React Intl example that uses shouldComponentUpdate() to deal with locales changing in the app.

See: formatjs/formatjs#58

this is a follow up: http://stackoverflow.com/questions/27010990/with-react-intl-how-do-i-fix-error-uncaught-referenceerror-no-date-format-nam

pages/react.hbs
"Load the Scripts onto the Page"
might be changed to "Load These Scripts onto the Page in this Order"