Different string count for D7 / D9 versions of potx

Hm, so the files are exactly the same. You can export a .pot file from the localize.drupal.org UI I think and compare the list of strings there if you don't have a better way yet.

FYI opened #3298360: Strengthen test by adding string count checking to each generated .po file to further strengthen the existing very strong test coverage on potx.

@sandurhs: ah, ALL of those in the diff seem to be twig sourced strings where the space before the replacement pattern gets eatean up. It seems to me that is a combination of PHP version and twig version. I can reproduce the same problem locally even on the PHP 7 version of potx (which has a bundled hardcoded Twig vendor directory). Probably the twig included with the module on Drupal 7 has this bug.

So https://github.com/twigphp/Twig/issues/3248 is the reason for the diffs in https://www.drupal.org/files/issues/2022-07-10/Drupal-10.0.0-alpha6-Potx... I believe. We need to keep the vendor twig version compatible with PHP 5 in potx Drupal 7 due to allowed PHP versions there, so we have some upper bounds as to where we can update it I think.

The binary thing I have no idea why it would show up.

Looking at the views mini pager example, this is where that comes from:

        <li>
          <a href="{{ items.next.href }}" title="{{ 'Go to next page'|t }}" rel="next"{{ items.next.attributes|without('href', 'title', 'rel') }}>
            <span class="visually-hidden">{{ 'Next page'|t }}</span>
            <span aria-hidden="true">{{ items.next.text|default('››'|t) }}</span>
          </a>
        </li>

Also the other two twig examples you cited are pipe-t examples. I wonder what would be special about them in Drupal 7 vs 9.

Looking at test coverage for the cases you mentioned in #6:

web/core/themes/claro/templates/node-add-list.html.twig

{%
  set add_bundle_message = 'You have not created any content types yet. Go to the <a href="@create-content">content type creation page</a> to add a new content type.'|t({ '@create-content': create_content })
%}

web/core/themes/olivero/templates/misc/feed-icon.html.twig

{% if title is not defined or title is null %}
  {% set title = 'RSS Feed'|t %}
{% endif %}

I think these in the tests should provide enough coverage, they cover similar cases where t is used as a filter in {%set%}:

{% set variableString = 'Variable string.'|t %}
{% set variableString = 'Variable string with @placeholder.'|t({'@placeholder': 'placeholder'}) %}
{% set variableString = 'Variable string with @translatedPlaceholder.'|t({'@translatedPlaceholder': 'translatedPlaceholder'|t}) %}

The default method thing from #13 was not covered, adding coverge for that in #3298454: Add more test coverage for Twig default value case.

I committed #3298454: Add more test coverage for Twig default value case, but that did not uncover a bug on Drupal 7 or 8 they were the same.

That said, before that I committed #3298467: Update dependencies: twig to 1.42.5, yaml to 3.4.41, polyfill-ctype to 1.19 which significantly updates Twig to fix the whitespace differences you noticed in #7.

I think given the expanded test coverage and updated Twig in Drupal 7, it would be nice to run another comparison. I suspect now that any remaining difference would be down to which files actually get found while parsing. Or some segfaulting or running out of time of the process for Drupal core at least. It takes a lot of time.

Can you try again with the current dev versions on Drupal 7 and 8/9 of potx and see what's the difference now?

I compared the strings of the current branches on 51 projects using an LLM: Drupal 11 core, 32 Drupal 11 contrib projects and the bluecheese theme, Drupal 7 core and 9 Drupal 7 contrib projects, and the test fixtures of potx for Drupal 5 to 8. The versions were 7.x-3.x at ddb3613 (with Twig 1.42.5 and symfony/yaml 3.4.41 from #3298467: Update dependencies: twig to 1.42.5, yaml to 3.4.41, polyfill-ctype to 1.19), 2.x at d22de3e, and 3.x at 66debe9. Each run was like drush potx single --folder, with the file names relative to the project.

All three versions scanned the same 11,197 files. 7.x-3.x and 3.x extracted the same strings, with the same contexts and plurals, in all projects but core and l10n_server: 3.x extracted 31 more JavaScript strings there, 30 in core and 1 in l10n_server. These are the calls fixed in 3.x by #3630552: JavaScript strings potx does not find: trailing commas, null arguments, template literals: a trailing comma right after the string, null in place of the arguments, and template literals. 7.x-3.x currently reports these calls as warnings, like "Drupal.t() calls should have a single literal string as their first parameter.", so it had 182 warnings for core, and 3.x 138.

2.x extracted the same strings as 7.x-3.x, except for diff: 2.x currently crashes on the config schema of diff, so its template of diff had none of the 209 strings. 3.x fixed that in #3630545: Config and YAML strings potx misses: invalid schema elements, schema of config dependencies, patterns without keys.

Other differences of the output:

• 7.x-3.x and 2.x currently write a wrapped @Translation string of devel with a raw newline, so their template of devel is not a valid .pot file. 3.x escapes the newline.
• 3.x reports the invalid config schema of diff and the broken YAML files of the potx test fixtures. 7.x-3.x does not report them.
• 7.x-3.x writes the installer strings into a separate template, with "(duplicate)" references. 3.x writes one template by design.
• All three versions write a singular and a plural entry with the same msgid in core and in Drupal 7 views, like "1 second" and "1 second"/"@count seconds". Gettext tools report these as duplicates, while Drupal has them as two different source strings.

So with the current branches, the strings of 7.x-3.x and 3.x are the same, except for the JavaScript fixes of 3.x which is good :)