Open oscarotero opened 4 years ago
tldr; I'd suggest to wait to see what's the next Twig-implementation looks like first, in order to avoid the complexity of an over-anticipated factorization.
dev
only so nothing blocking users from using it with any Twig version. Still, this could be improved by putting Timber-specific in the wp-cli i18-command
package. Twig-Scanner can load arbitrary extension (or arbitrary Twig Environment) previous to parsing, then the tests could just use a fixture for its own Twig extension/function/filter. Just keep in mind that Timber is a Twig extension (as is the i18n extension) except that it still lacks the formal addExtension mechanism.ParsedFunction
based on Twig FunctionExpression. But if we were to support the {% trans %}
tag, the current parser would not fit. A CMS like Grav preferred a t
Twig filter.I suggest to first wait a couple of days for the full stack to be done, test (I'd like to regenerate my own POT files with the new stack), and play with wp-cli/Timber initialization and maybe fix wp-cli i18n-command gettext-5 support down the road and then having a look back :)
Yes, sure. There's no rush 😄
The idea is that this repository should contain only the general code to scan Twig templates and create a different package
gettext/timber-scanner
with the other stuff needed for timber. Advantages:@drzraf What do you think?
If you're ok, can you please create a new package? Or if you cannot, let me know and I can do it.