Make it i18n friendly

[daviddias]

@satazor implemented this for js.ipfs.io using react-intl and it is super easy to work with. @satazor, wanna shine some light here?

[satazor]

Yes we used react-intl in js.ipfs.io mainly because it's made for react and supports:

• messages with placeholders
• date & time
• relative dates (xxx ago)
• number formatting, including currency

The strategy we went for was to have a intl folder that containes everything related to i18n. Contributors just need to follow a few steps to add a new language, which are detailed in the README.

Note that ideally, you would lazy load the locale files. More specifically, you should only call addLocaleData when a language is requested. Moreover, if you use nested messages for readability, be sure to flat the messages object because nesting is not supported. You may use https://github.com/IonicaBizau/obj-flatten to flatten the messages.

I think that's all, feel free to ask more questions and I will happily provide help.

[lidel]

cc ipfs/ipfs-gui#50 (Meta: Translation Project for IPFS GUIs)

[lidel]

Some relevant notes: https://github.com/ipfs/i18n#adding-i18n-to-your-project
Good prior art can be found in WebUI.
I think we won't have a lot of string in revamped version.
As soon initial UI lands, may be a good idea to prioritize i18n and do it sooner than later, that way translation team will have more time to work on it before shipping :)

[hacdias]

I can add it on the PR I'm working on. It's not that much 😄

[lidel]

@hacdias as long the change set is not too big.

(Would be cool to have it in separate PR, so we can link to it as an example for other projects that want to add i18n)

[hacdias]

@lidel it would probably introduce a lot of changes to the code I wrote so far, but basically just adding translation functions. We can leave it for another PR just to keep things separated. #662 is already getting really big, but it couldn't be other way since it introduces really deep changes.