[dev] Update Translation action

[kalessil]

• Per-category existing translations index;
• Project scanning and collecting per-category messages;
• Searching mismatches:
  • Non-existing translations;
  • Unused translations;
• Fixing mismatches;

[kalessil]

@brandonkelly, can you share some details regarding this:

• Is {%- includeTranslations ... -%} required for processing {% set updateText = "1 update available"|t %}
• {{ 'Craft is running in Dev Mode.'|t }} not included, but used
• is it twig or something else mixed into .html-files?

[brandonkelly]

The {% includeTranslations %} tag and the |t filter are Craft CMS-specific Twig extensions. Not things this plugin should worry about.

Although it does bring up a good question: how should the plugin account for dynamic calls to Yii::t()? For example that {% includeTranslations %} tag maps to a function that does this (simplified):

public function registerTranslations($category, $messages)
{
    foreach ($messages as $message) {
        $translation = Yii::t($category, $message);
        // store the translation for later use ...
    }
}

So to resolve $category and $message in this case, the plugin would need to be smart enough to realize that Yii::t() is being called within that foreach-loop, and find any calls to that includeTranslations() function, and analyze the $messages array being passed in.

I'm assuming that would not be easily done though. So as much as I was hoping to keep this plugin application-agnostic, maybe we need to add one little Craft-specific feature: when indexing calls to Yii::t(), also index any calls to craft\web\View::registerTranslations(), and index each of the values in the array being passed to its $messages argument. Is that feasible?

[kalessil]

This case is not feasible for plugin v1 (not a rocket science, but needs time).

For twig I already have to extract translations: https://github.com/kalessil/yii2inspections/blob/master/src/main/com/kalessil/phpStorm/yii2inspections/actors/upadateTranslations/ProjectTranslationTwigCallsFinder.java#L34. I think that in this context we can skip processing includeTranslations. Am I right, or?

[brandonkelly]

If we are going to have any Craft-specific support in the plugin, it should be for Craft 3.0, which is hitting Beta in the coming weeks. I just gave you access to the repo (email coming soon on how to get it installed), but here are the relevant changes:

• the |t and |translate filters will now be in one of these formats:

  {{ "message"|t }} <-- default category to "site" ({ "message"|t({ token': "value1", ... }) }} <-- default category to "site" {{ "message"|t('category') }} {{ "message"|t('category', { token1: "value1", ... }) }}

• the old includeTranslations functionality is now provided by craft\web\View::registerTranslations()

• the {% includeTranslations %} tag has been removed. Templates that were calling it now call the new registerTranslations method directly:

  {% do view.registerTranslations('category', ["message1", "message2", ... ]) %}

I think that in this context we can skip processing includeTranslations. Am I right, or?

There are places in PHP that are calling View::registerTranslations() as well, so it would be helpful to specifically look for places that are calling that in PHP.

[kalessil]

Thank you for giving the access @brandonkelly, what caught my eye is that translations structure is as Yii uses - simplifies my code a lot. Will follow up on this with specific answers.

EDIT:

• t/translate calls with the group: supported now
• Craft::t()/Yii::t(): simplified now (better performance as no APIs deviation now)

[brandonkelly]

Ah yes, Craft::t() is identical to Yii::t() in 3.0, unlike 2.x.

[kalessil]

Main part is done, #7, #8 are follow up tickets for consideration.