[wp-trac] [WordPress Trac] #41305: Add lazily evaluated translations
WordPress Trac
noreply at wordpress.org
Mon Mar 18 16:43:38 UTC 2019
#41305: Add lazily evaluated translations
-------------------------------------------------+-------------------------
Reporter: schlessera | Owner:
| timothyblynjacobs
Type: enhancement | Status: assigned
Priority: normal | Milestone: 5.2
Component: I18N | Version: 4.8
Severity: normal | Resolution:
Keywords: has-patch early dev-feedback needs- | Focuses: rest-api,
testing | performance
-------------------------------------------------+-------------------------
Comment (by mnelson4):
Thanks for the thought you put into this, @TimothyBlynJacobs.
> I'm not sure whether this should be considered an acceptable level of BC
breakage. If not, I think we should reconsider using _l and esc_attr_l
etc...
IMO this would be a great middleground.
> Additionally, lazily translating every string isn't necessarily a
performance boost.
So there is no point in lazily evaluating some strings (one that we know
for certainty will be evaluated). So, it might be handy for client code to
have the option to have the option to choose either `__` or `_l`.
> Lazy translation functions would be easy to "polyfill" for later
versions by just making them aliases for their __ variants.
Are you suggesting we'd add `_l` in a patch to 5.1.x, for example? Except
it would actually only be a wrapper for `__`? I think that would be good.
I'd still be inclined to do a version check though, to at least make sure
my code is executing on a version of WP that has those "pollyfill"
versions of `_l`, but only do that on plugin activation or something (not
before every call to `_l`).
IMO, as much as I like the current implementation, I think it's too much
of a breaking change. Adding `_l` sounds good though.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/41305#comment:59>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list