Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make i18n functions filter their return values #27966
Make i18n functions filter their return values #27966
Changes from 2 commits
f9b484a
99d3466
5176c06
1efa483
4a3c2d7
2866eb9
883bc53
a0a0a73
e955c4c
40cb141
a320295
815a422
f8eca3a
d6ae239
8ab3436
f34fcf0
f9650fe
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
createI18n
function shouldn't always use the globalapplyFilters
function. It should allow for supplying a custom instance of theHooks
object returned bycreateHooks
.The
hooks
andi18n
packages have a similar structure:createI18n
orcreateHooks
function that creates aI18n
orHooks
object that has methods like__
orapplyFilters
__
andapplyFilters
are -- methods of one specific object instance that are used as functions.To keep the separation between default singletons and custom instances,
createI18n
should take a newhooks
parameter:use this
hooks
parameter to get to the rightapplyFilters
:and the
default-i18n.js
module should configure it with the default hooks:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsnajdr I've updated the PR to follow this approach. The
hooks
arg is optional, and no filters will be called if it is not provided. default-i18n provides a copy ofapplyFilters
from@wordpress/hooks
when creating the default instance. Feedback welcome.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Core recently added also domain-specific filters named
i18n.gettext_${ domain }
:https://core.trac.wordpress.org/ticket/49518
Can we add them here, too, to keep the APIs as similar as possible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsnajdr I'm happy to update to include that, however there is a slight difference here in implementations. In core "domain" is defaulted to "default" if not provided, but the JS methods don't do that (leaving "domain" as undefined). Given your comments previously about re-use of the resulting object I'm not sure whether we should:
a) update the
__()
etc. method signatures to set domain to "default" if not provided,b) call a "default" filter if
typeof domain === 'undefined'
Any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@leewillis77 The b) option looks better to me as it achieves the goal without changing the library too much. But I'm not really sure. I noticed the new
gettext_${ domain }
hooks when comparing the hooks in this PRs to what's already in Core/PHP. Anyway, adding these extra hooks is not a blocker and can be done at any later time.