Hello all–
Have we determined the proper pattern yet to handle localization within an OWA? Are there any examples yet of of ways to go about this?
Thanks! Mark
Is there any reason we wouldn’t adopt the best practices of the client technology being used?
For example:
I agree that we should adopt a well-supported existing library. Is react-localization particularly the one?
When I googled for react 18n that one didn’t come it in the first few hits. This one seems to have a lot of stars on github: https://github.com/yahoo/react-intl
Definitely agree we should use an existing, well-supported library. I didn’t clarify, but I was specifically talking about the React case. Sounds like we have some options but need to do a little more assessment of which is the best/most mature.
Take care, Mark
I definitely agree with using an existing best practice library. One question I’d pose though is whether it would be prudent to abstract this away behind our own API interface. This would allow us to use something like react-intl or react-localization now, but not necessarily be locked into this particular library if we want to change it over time. We would simply change our implementation in one place.
This question might apply to other similar “framework” libraries as well.
Interested in other thoughts… Mike
An alternative approach to this is to pick an existing tool that can be used across multiple JS frameworks.
react-intl led me to https://formatjs.io/ which states
For most web projects, internationalization happens in the template or view layer, so we’ve built integrations with common template and component libraries: React, Ember, Handlebars, and Dust.
I don’t know if this tool is the best, but I like the idea.