Teach website sidebar to prefer en-US
Teach website sidebar to prefer en-US

Summary:
When I reran the website build toolchain for the 0.9.1 release I ended up updating the `metadata.js` file:

https://github.com/facebook/relay/commit/88c41e94945092655a7f841e2d25b27f6f5fcf0c

This in turn meant that we had multiple documents with the same id; eg:

- thinking-in-graphql

But different permalinks:

- docs/thinking-in-graphql.zh-CN.html
- docs/thinking-in-graphql.html

When I committed and pushed the generated documentation, ie:

https://github.com/facebook/relay/commit/eef148d1061b06e7838e2d12993f87e3d0a4bbcf

I saw that our sidebar table of contents was now using the localized version of the document; ie:

> 深入理解 GraphQL

instead of:

> Thinking in GraphQL

The solution for now is to always prefer non-localized resources in the sidebar, but in the long term we'll want the localized version of each page to prefer localized links in the sidebar, if they exist. This may be tricky to implement, however, because we don't control the gh-pages environment and so can't necessarily implement the logical `Accept-Language` solution (although perhaps GitHub will... maybe they already do?). For now just getting the fix out. The updated, published documentation went out in:

https://github.com/facebook/relay/commit/52b908ddf53c66d2c33555c6c8c2a40449ee29bd

Aside: this commit takes care to preserve ordering, so that the "find first element which doesn't have any previous" logic can rely on it. But this is not well-defined behavior because (I think) the order in which we're visiting the source files (as returned by `glob.sync(MD_DIR + '**/*.*')` in `website/server/convert.js`) is actually filesystem-dependent. On HFS+ (macOS) this happens to be lexicographically ordered, but I know of other filesystems where it is dependent on things like inode metadata layout and such.

Closes https://github.com/facebook/relay/pull/1238

Pulled By: wincent

fbshipit-source-id: dd46ba2ba2b9972afd8a720a31407c8d3f29343c

facebook/relay,benjaminogles/relay,xuorig/relay,wincent/relay,yungsters/relay,xuorig/relay,voideanvalue/relay,chirag04/relay,xuorig/relay,freiksenet/relay,xuorig/relay,benjaminogles/relay,kassens/relay,atxwebs/relay,iamchenxin/relay,apalm/relay,kassens/relay,chirag04/relay,facebook/relay,wincent/relay,chentsulin/relay,cpojer/relay,iamchenxin/relay,atxwebs/relay,kassens/relay,wincent/relay,yungsters/relay,wincent/relay,dbslone/relay,cpojer/relay,zpao/relay,voideanvalue/relay,iamchenxin/relay,facebook/relay,kassens/relay,chentsulin/relay,facebook/relay,voideanvalue/relay,cpojer/relay,chirag04/relay,freiksenet/relay,josephsavona/relay,rosskevin/relay,josephsavona/relay,voideanvalue/relay,apalm/relay,josephsavona/relay,benjaminogles/relay,zpao/relay,cpojer/relay,atxwebs/relay,xuorig/relay,rosskevin/relay,atxwebs/relay,dbslone/relay,facebook/relay,iamchenxin/relay,kassens/relay,voideanvalue/relay,voideanvalue/relay,freiksenet/relay,facebook/relay,zpao/relay,chentsulin/relay,kassens/relay,wincent/relay,apalm/relay,wincent/relay,xuorig/relay,yungsters/relay