Make gettext functions filterable

[swissspidy]

Description

Fixes #12516 by applying filters to all the gettext function in the i18n package.

How has this been tested?

Manually added some filters to these hooks.

Types of changes

New feature (non-breaking change which adds functionality): added new filters.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[swissspidy]

Ugh. Travis CI says npm run check-local-changes failed, but locally it works just fine.

[aduth]

Personally, I don't find this to be a pressing enhancement to consider, and while normally I'd not have such reservations, the translate functions are very hot paths. applyFilters is not especially "expensive", but without a use-case beyond broad flexibility and feature parity, it doesn't feel very compelling.

Alternatively, we could consider optimizing for the assumption that a filter will not be present in the majority of usage, and use a monkey-patching technique in overriding the translation functions when a filter is applied (see #8602 (comment)).

[swissspidy]

Yeah it's definitely not a pressing enhancement, but sure something that will come up when JS I18N is getting more traction now with 5.0 and beyond. Parity and flexibility for devs is definitely important to some degree, IMO.

Your monkey-patching idea sounds interesting, but I guess we would need to check first whether it would be worth the effort. I was thinking about doing some benchmarks or something, but I wouldn't know where to start there.

[swissspidy]

For the record, we discussed some use cases at WCUS, mainly #12407 and https://core.trac.wordpress.org/ticket/45425#comment:10. It's certainly not ideal that the user experience for certain locales got worse.

As for the technique used here, we could do some benchmarks to see whether monkey-patching should be explored or not. Although that could also be done in a later version.

[gziolo]

@aduth - we probably should also optimize applyFilters to return early when there are no hooks to process. See:

https://github.com/WordPress/gutenberg/blob/master/packages/hooks/src/createRunHook.js#L22-L33

It makes me think that having to run filters on every re-render might be bad for the performance of the application.

[gziolo]

Okey, I see #12517 (comment) which aligns with my comment.

[aduth]

Yeah, it's not too horrible though. Outside of some conditions and a one-time setup, it amounts to incrementing the runs each time it's called.

[gziolo]

It looks like this is something that we need to decide about whether we continue working on this PR or we close it and keep it as a future reference when we decide it becomes necessary.

[swissspidy]

@gziolo @aduth What's the way forward here? A discussion at the next weekly meeting together with some core i18n / polyglots people involved?

[aduth]

A discussion at the next weekly meeting together with some core i18n / polyglots people involved?

Which weekly meeting are you referring to? I can have it included it in the agenda of tomorrow's JavaScript chat if you'd like.

[swissspidy]

Yeah that could work.

[aduth]

Recap from aforementioned meeting: https://make.wordpress.org/core/2019/04/10/javascript-chat-summary-april-9th-2019/