You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is this one: We want to be able to use wp.i18n lib in JS from third-party themes/plugins. There are almost no problem that would stop us from doing so, besides a couple of small inconveniences
Append item into existing Jed instance
One thing that's currently almost impossible is to add existing translations into the global wp.i18n instance. Of course one could go about:
This solution is not viable because we have to re-use gutenberg domain and that's the biggest issue. Also, there's no way to swap out the current domain with the global wp.i18n.__() helper, just like we do on the PHP side __('Text', 'custom-domain').
Without these points being addressed there's no reason to even think about publishing this library to NPM. It just won't be usable outside of the Gutenberg scope.
Possible Solution
One way to deal with that would be to allow the domain as the second argument of the __() family of helpers. You could always do const __ = (text, domain = 'gutenberg') => {...} internally, to keep backward compatibility with your own code.
Thanks for considering that!
BTW, I have tried a couple of things locally and come up with some simple tests for wp.i18n. Would you be interested in getting a PR which would contain them? andreiglingeanu@feb0397
Issue Overview
The problem is this one: We want to be able to use
wp.i18n
lib in JS from third-party themes/plugins. There are almost no problem that would stop us from doing so, besides a couple of small inconveniencesAppend item into existing
Jed
instanceOne thing that's currently almost impossible is to add existing translations into the global
wp.i18n
instance. Of course one could go about:This solution is not viable because we have to re-use
gutenberg
domain and that's the biggest issue. Also, there's no way to swap out the current domain with the globalwp.i18n.__()
helper, just like we do on the PHP side__('Text', 'custom-domain')
.Without these points being addressed there's no reason to even think about publishing this library to NPM. It just won't be usable outside of the Gutenberg scope.
Possible Solution
One way to deal with that would be to allow the domain as the second argument of the
__()
family of helpers. You could always doconst __ = (text, domain = 'gutenberg') => {...}
internally, to keep backward compatibility with your own code.Thanks for considering that!
BTW, I have tried a couple of things locally and come up with some simple tests for
wp.i18n
. Would you be interested in getting a PR which would contain them? andreiglingeanu@feb0397Related Issues and/or PRs
#3955
Todos
__()
family of helpersThe text was updated successfully, but these errors were encountered: