As an fyi, it looks likely that we are going to be going with the react-intl library for internationalization within the new OWA that we are building for lab entry, and in openmrs-react-components will likely build some utility functions for setting up react-intl within an OpenMRS OWA.
Our main reasons for choosing react-intl, besides the fact that it appears to meet our needs, is that it seemed to be the most highly-used and highly-rated React library for internationalization.
We’d hope that whatever is used within openmrs-react-components becomes the OpenMRS standard, so if anybody has thoughts/arguments why another library might be better, we are interested in hearing them.
There are strong arguments for going with what is simple (low learning curve) and widely supported; however, if there’s an option that’s equivalent in other respects and is not bound to a specific JS framework, it would be an important factor to consider.
@burke, after going through the links you shared, I get why i18next seem okay to you, because I have used it before. Before last week I haven’t even heard react-intl either but comparing both right now I don’t see any major differences, they both have the same approach to setting up (comparably low learning curves), I would say i18next is good for being flexible in it’s approach for providing helpers and api’s to use for creating stuffs like HOC’s and most importantly giving users the ability to utilise any custom approach you have in mind for it’s use case and at the same time I would applaud react-intl for providing react HOC’s and more api functionality than that from i18n
For what it’s worth, although conceptually I see value in not being bound to a specific JS framework, I’m not sure I understand what that means practically in the context of a translation library. Beyond message codes (which are generally in a standard key/value pattern across all libraries) what translation code would we really be interested in sharing across, say, React and Angular?