Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twig filters support #7

Open
rauwebieten opened this issue Jun 25, 2021 · 2 comments
Open

Twig filters support #7

rauwebieten opened this issue Jun 25, 2021 · 2 comments

Comments

@rauwebieten
Copy link

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

@drzraf
Copy link
Collaborator

drzraf commented Jul 9, 2021

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.

@tvdijen
Copy link
Contributor

tvdijen commented Jul 14, 2022

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants