Closed opatut closed 8 years ago
I'm hesitant to do that because it increases the surface area we have to maintain. Currently they're private, which means we don't have to directly test them and we're free to refactor them.
Curious, what's your complex logic for phrase-finding? I've never seen anyone implement i18n with anything besides key → value lookup, while swapping maps based on locale.
I'm fetching multiple dynamic overlays for the phrases object from the database. I don't want to fetch all of them, and certainly not merge multiple (huge) phrases objects each time or keep all of them in memory.
So I have my own key -> phrase resolution which I can freely optimize (i.e. Lookup in order from different sources).
Currently I am working around the missing exports by creating an instance with just one key and then interpolating that key. But that feels dirty and I am unsure of the overhead of creating new Polyglot
instance each time I translate a string.
I could add tests and documentation if that helps... ;)
They'd certainly need both tests and documentation were they to be exposed.
I wonder if perhaps a better approach would be to create a function that takes a phrase, a locale, and options (including substitutions), call that internally in t
and polyglot
, and then expose that one function directly?
Yeah, I could perform that refactoring and add tests. Brb :)
See updated #75.
Sorry for the large diff, somehow had to move stuff around to make eslint happy :)
Closed in #75.
I'd love to use
choosePluralForm
andinterpolate
without using the phrase-finding stuff (I have a much more complex logic for that and don't want to merge objects to create the phrases object every time).Could we have them exported as statics on the Polyglot object?