Open rauwebieten opened 3 years ago
The very nature of Twig makes easy for any user (eg: a theme developer of framework X or a WordPress plugin developer) to add custom tags/filters/function Resulting Twig markup (they want to translate) would look invalid if that corresponding theme/plugin/addon/extension is not loaded
A custom loader for a given framework/CMS is definitely the way to go (any hardcoded list of filters/functions is rather not)
Such a loader should be able to load its necessary themes/plugins/addons/extension...
In the end all is needed is that createTwig
returns a Twig Environment.
The TimberScanner
bootstraps a Twig Environment (custom filters & functions, but could be also a Twig extension or even a framework that needs runtime defined extensions).
TimberScanner
has its own limitations (discussed #2) and we definitely would prefer that a Symfony, Laravel, Craft, Grav, ... loader avoided that. There is a tradeoff between bundling loaders (like Monolog for example) and over-splitting packages in the sake of a perfect single-responsability principle).
But I'd say that a PR introducing a new loader could be definitely interesting.
@rauwebieten You still have that clone with Twig-filter support? I'm really curious about it and I think it would make this library 10 times more useful
Hi,
I've cloned you lib, and have been playing with it a bit.
I've added some code in the twig functions scanner to support twig filters in addition to twig functions. I think will us allow to support frameworks that use twig filters as their translation method, like Craft CMS and Symfony.
As I understand reading the other issues, it is the goal to make each scanner have its own repo. This means we should have a base-twig-scanner repo, which is used by concrete scanners: twig-craft-cms-scanner / twig-symfony-scanner ?
I'm happy to help out, please let me know. Peter