ease inheritance in order to support Twig/Timber

[drzraf]

It would be nice for wp-cli make-pot to support twig template out of the box.
Some of the building blocks:
timber/timber#1753
umpirsky/Twig-Gettext-Extractor#60

[swissspidy]

I just read through these issues as well as timber/timber#1754 and https://timber.github.io/docs/guides/internationalization/.

Is Twig so popular in WordPress space and is Timber the de facto standard for it? Where would we draw the line when someone else comes with their templating engine and wants this included in wp i18n make-pot?

I am not really sure whether this is something WP-CLI should handle.

The Gettext library we use already supports Twig extraction:

https://github.com/oscarotero/Gettext/blob/eea87605224d25125a39a83fbc9bc1c28d16bb7a/src/Extractors/Twig.php
https://github.com/oscarotero/Gettext/blob/master/tests/assets/twig/input.php

If we can easily use that to make it work with Timber, I'm open for looking at it. Otherwise I'm not sure it's worth the effort.

Also, good to keep in mind that with this we'd need to scan (not necessarily load) every PHP file twice, once for good old gettext and once for Twig.

[drzraf]

I'll try to offer a PR, but I hope bootstrap'ing WP is not a showstopper...
It's needed to:

1. load twig and its filters
2. load custom twig filters/functions from functions.php (if any)

[swissspidy]

Personally I really don‘t want to load WP just because some projects might use Twig.

People should be able to use this command in environments where they need to create POT files on the fly, e.g. on Travis CI, the WordPress.org infrastructure, or in projects like https://github.com/wearerequired/traduttore

Perhaps a feature flag or a new sub-command could be used for this, but I feel like in that case this should be handled in a new command offered by Timber. That command can of course extend this one‘s code, so there shouldn‘t be much duplicate code.

@schlessera thoughts?

[drzraf]

I fully understand the concern, but how to handle writing to one common PO file (in one run) while having two different bootstrap levels?

[swissspidy]

You mean one common POT file?

Let's say your custom command is wp timber make-pot which creates a new file called twig.pot.

Then, you can run wp i18n make-pot --merge=twig.pot to create one single POT file containing all translations from Twig, regular PHP code and JavaScript code.

Of course you could combine these commands, e.g. wp timber make-pot && wp i18n make-pot --merge=twig.pot.

[drzraf]

Then, you can run `wp i18n make-pot --merge=twig.pot` to create one single POT file containing all translations from Twig, regular PHP code and JavaScript code.

(I wondered whether `make-pot --twig` could have be run after_wp_load while keep `make-pot` before_wp_load). It'd be annoying not being able to reuse the hundreds of useful lines already in that package. => #54

[swissspidy]

(I wondered whether make-pot --twig could have be run after_wp_load
while keep make-pot before_wp_load).

I wondered the same yesterday, but I'm not sure it's possible. Also, it could lead to unexpected results for users and would need thorough documentation.

It'd be annoying not being able to reuse the hundreds of useful lines already in
that package.

That's why I suggested extending this command. I bet it's possible to extend the MakePotCommand class in your own code.

Perhaps you'd need to require this package in composer and use WP_CLI::add_command( 'i18n make-pot', 'My_Extended_Makepot_Command' ); to override the existing one.

Either way, you wouldn't have to rewrite things from scratch.

I don't know the internals of WP-CLI that well yet, hence pinging Alain before to get his thoughts to figure out the best way of extension here.

[drzraf]

Moving argument handling outside __invoke would ease reuse: class MakeTimberPot extends \WP_CLI\I18n\MakePotCommandstill seems a bit difficult because of __invoke magic;

[swissspidy]

Makes sense. I‘ll try to have a look over the weekend. If you have a proposed solution in mind, feel free to create a PR :)

[drzraf]

Thank you!

In the meantime, here is my working code for Twig extraction:

<?php

use Gettext\Translations;
use Gettext\Extractors\Twig;
use WP_CLI\I18n;

final class TwigExtractor extends Twig {
	use WP_CLI\I18n\IterableCodeExtractor;

	public static $options = [
                'twig'            => NULL,
		'extractComments' => [ 'translators', 'Translators' ],
		'constants'       => [],
		'functions'       => [
			'__'              => 'text_domain',
			'_e'              => 'text_domain',
			'_x'              => 'text_context_domain',
			'_ex'             => 'text_context_domain',
			'_n'              => 'single_plural_number_domain',
			'_nx'             => 'single_plural_number_context_domain',
			'_n_noop'         => 'single_plural_domain',
			'_nx_noop'        => 'single_plural_context_domain'
        ]
    ];

    public static function fromString($string, Translations $translations, array $options = []) {
        $options += static::$options;
        $twig = $options['twig'] ?: self::createTwig();
        $source = $twig->compileSource(new Twig_Source($string, ''));
        $functions = new I18n\PhpFunctionsScanner( $source );
        $functions->saveGettextFunctions( $translations, $options );
    }

    private static function createTwig() {
        $twig = new Twig_Environment(new Twig_Loader_Array(['' => '']));
        $twig->addExtension(new Twig_Extensions_Extension_I18n());
        $timber = new TimberTwig();
        $timber->add_timber_functions( $twig );
        $timber->add_timber_filters( $twig );
        return static::$options['twig'] = $twig;
    }
}

• references to Twig/Timber
• depends upon Don't overwrap WordPress i18n functions timber/timber#1753
• Twig parsing by Timber is made possible because custom filters from theme's functions.php have been loaded
  (But the WP_CLI_Command class is a mess.)

[drzraf]

Could you also drop "final" from PhpFunctionsScanner? It's useful to inherit from it.

[schlessera]

I don't think Twig or Timber is popular enough to warrant bundling functionality for them with standard WP-CLI, especially if it needs major changes to the way the command runs.

This is perfectly fine as a third-party command, though, and we can make sure that it is straight-forward enough to extend the bundled command to enable said third-party command.

Note: You can extend a bundled command with a third-party command and have that override the bundled command when installed through the package manager.

This could be something like this (untested):

class TwigAwareMakePotCommand extends MakePotCommand {
   public function __invoke( $args, $assoc_args ) {
      $twig = Utils\get_flag_value( $assoc_args, 'twig', false );

      // For Twig handling, defer execution to after WP was loaded.
      if ( $twig ) {
         WP_CLI::add_hook( 'after_wp_load', [ $this, 'process_twig' ] );
      }

      // Continue with bundled command execution.
      parent::__invoke( $args, $assoc_args );
   }
}