Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
i18n: Replace Jed with Tannin #11493
This pull request seeks to propose an internal refactoring of the
Context: Summarized at WordPress/packages#101, Jed's implementation has a critical performance flaw in that it parses and compiles the locale plural forms expression every time a translation function is called with pluralization or when locale data is not explicitly provided (e.g. default English). While memoization remedies the issue, it's more a bandaid solution in that (a) the underlying operation is still expensive† and (b) it incurs an additional cost of memory storage of redundant cached data. Tannin addresses these issues by computing the parsed evaluator of plural forms at most a single time, and by having more efficient expression parsing and evaluation to begin with.
† Even with caching, the current Gutenberg master incurs a plural forms parse nearly 300 times during the initial load.
There should be no impact on the application. There are numerous layers of unit testing to validate variations of translations, but verify that the correct strings are shown in general usage, notably:
Ensure unit tests pass:
Looks good, and nice job humbly hiding the fact you wrote Tannin ;)
The only minor concern I have here is that there seems to be a decrease in useful dev feedback when something is wrong. Intentional?
I think it's fine to keep it separate. Andrew worked on this as a personal project and we can use it like we use any other personal project. We already use other personal packages from Andrew and Me and other people outside of the community. While I'd be fine giving my projects to WordPress, I think it doesn't make sense to tell people: if you want to us use this project, move it to WordPress.
Without belaboring the point, it was a hobby / passion project intentionally developed outside regular constraints / commitments. While I don't have a strong resistance to transferring ownership, I also don't see that it be strictly necessary, nor think there should be an expectation that all hobby projects of any WordPress contributor be brought under the umbrella of the organization.
And as with any permissibly-licensed open-source project, it's entirely forkable should I at any point go rogue
I've pushed a rebased copy of the branch.
Regarding error handling, I've restored the
I'd actually reinstated it to