Timber/twig compatibility

I intend to add twig support, but it’s not a very common request and there are too many more important features in the pipeline.

I’ve noted your feature request. For now you’ll have to generate POT files using some other software.

would it be possible to make Loco to support .twig files as well?

+1

If you want to generate POT files with Loco you can add the twig extension in the settings page and put the Twig comment at the top of the template(s):

{#<?php#}

The development trunk (2.0.16-dev) has a small fix that means you don’t need to use this comment hack.

Just add twig as a PHP file extension and Timber-style i18n functions can have their strings extracted.

I’m yet to add full/extensible Twig support, as this has proved more difficult than expected. Hence the current methods will only extract function calls that look like PHP function calls. i.e. the following will work:

{{ __("string","domain") }}

But the following won’t work:

{{ "string" | translate("domain") }}

Neither will:

{% translate from "domain" %}string{% endtranslate %}

That’s great timwhitlock.
Thank you for working on this feature!

Hi! I’m enjoying the new feature, thanks a lot for this! I’ve however noticed that in this code for example the strings inside attributes (‘Go to previous page’ here) don’t make it into the .pot file. Other strings do make it (‘Previous’ here).

{% if before_after and pagination.prev %}
  <a href="{{pagination.prev.link}}" aria-label=" {{ __('Go to previous page', 'domain') }} " class="c-button c-posts-pagination__item c-posts-pagination__item_prev">{{ __('Previous', 'domain') }}</a>
{% endif %}

@certainlyakey That makes sense. The whole thing is parsed as if it was PHP, so everything inside the attribute will appear as a literal string.

Basically this is a cheat until I implement a proper Twig parser. I’ve looked into it using the Twig library itself, but ran into numerous complexities. I’m more likely to write a bespoke parser, but that’s on the back burner for now.

I suppose an alternative cheat would have been to replace all {{ with <? before tokenizing, but this would be imperfect too and prone to different problems.

Until a proper parse is available, just bear this limitation in mind and assign Twig variables for use in HTML attributes.

Thanks for the effort and a hint. I’ll change those to use variables instead for now.