-
Notifications
You must be signed in to change notification settings - Fork 52
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
Functions scanner for Twig AST #59
Conversation
cd38af8
to
a21a89a
Compare
I'm open to removing the However, as already stated in #52 (comment), I don't think Twig support is a good fit for bundling right now. Also, please note that we don't accept code that comes with individual copyright or changes licensing. |
a21a89a
to
1cc531c
Compare
1cc531c
to
bce5533
Compare
|
|
As #62 has been merged, I'm closing this pull request now. Getting rid of extensibility limitations to make third-party Twig support viable can be done in a fresh PR. |
I updated #52 (comment). |
@oscarotero: would it fit better there? |
@drzraf I'm not a twig user so don't get the difference between this extractor and the one currently in Gettext. |
Gettext current one:
advantages:
disadvantage:
Proposed one:
advantages:
disadvantages:
¹ It's simple (and thus common) to extend Twig with additional filters/functions. (That's what Timber does for handling Twig i18n the-wordpress-way). But all these filters and functions must be defined before parsing the template. A good scanner+extractor must let user hook in the process to register their extensions on the Twig parser. |
@drzraf Ok, it looks fine to me. I don't care about don't reusing PhpCode. It was created originally to scan php code, not to reuse by other template based extractors. I only have this suggestions:
If you want to work in a pull request, I'd appreciate that. |
Current Twig parser operate by 1. Transforming Twig as PHP code = tokenize() + parse() + render() 2. Using a PhpCode extractor (and its specific configuration about function name) Disadvantage: * Twig rendered PHP code can be transformed/wrapped in call_user_func() making that gettext functions undetectable by PhpCode extractor. (See for example timber/timber#1753). * Can't handle templates making use of custom Twig extensions (very common) This patch offer an extractor that: * Parse Twig generated AST tree (= tokenize()+parse()) * Recursively iterate over node three to find function gettext calls. Advantages: * Operating sooner, at the AST level, Twig expressions like `{{ __("foo", "domain") }}` aren't yet wrapped. * More robust because it directly iterates over the AST from Twig parser instead of looking at PHP source-code. * Supports initialized `$twig` environment, thus supporting user-defined extensions? * Possibly more efficient. Ref: wp-cli/i18n-command#59
FTR: PR at php-gettext/Gettext#195 |
I would have preferred to submit this to upstream oscarotero/Gettext but the way i18n function wrappers work make it a bit difficult (It's easier to inherit from
wp-cli
PhpFunctionsScanner
)Note: This extractor work at a "higher" level than current one (which usually run a PHP extractor after a Twig-compilation pass).
#52