[Resolved] WPML String Translation no longer detects new strings added in Twig templates

Thank you for your feedback.

Unfortunately, I cannot provide project-specific recommendations on how to structure or maintain your Twig templates. The officially supported approach is to register strings using PHP. You can find more information about WordPress internationalization here:

WordPress Internationalization Guide:
https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/
hidden link
https://developer.wordpress.org/plugins/internationalization/

Based on the available information, I can share the following suggestions:

1. What is the recommended way to register strings from PHP for use in Twig templates?

You can keep Twig as the presentation layer and handle string registration and translation retrieval in PHP.

For example:

function theme_t( string $name, string $default, string $context = 'Theme strings' ): string {
    do_action( 'wpml_register_single_string', $context, $name, $default );
    return apply_filters(
        'wpml_translate_single_string',
        $default,
        $context,
        $name
    );
}
$context['i18n'] = [
    'read_more' => theme_t( 'button.read_more', 'Read more' ),
    'search_placeholder' => theme_t( 'search.placeholder', 'Search' ),
];
Timber::render( 'template.twig', $context );

Twig:

<em><u>hidden link</u></em>
<input placeholder="{{ i18n.search_placeholder }}">

WPML provides the following hooks for this purpose:

- wpml_register_single_string – register strings
- wpml_translate_single_string – retrieve translations

Documentation:

https://wpml.org/wpml-hook/wpml_register_single_string/

2. Is a centralized PHP file acceptable?

Yes, a centralized i18n.php file, or separate files per component/block, can be a reasonable long-term approach. For larger projects, keeping strings close to the components that use them may improve maintainability.

3. Is there a recommended pattern for block-based architectures?

We do not have an official WPML-recommended pattern for this use case.

One possible approach would be:

function get_card_block_i18n(): array {
    return [
        'title' => theme_t( 'blocks.card.title', 'Featured article', 'Theme blocks' ),
        'cta'   => theme_t( 'blocks.card.cta', 'Read more', 'Theme blocks' ),
    ];
}

This function would only be called when the corresponding block is rendered.

For grouped block/package-style strings, WPML also provides:

wpml_register_string
wpml_translate_string

Documentation:

https://wpml.org/wpml-hook/wpml_register_string/

4. Is there an automated migration path for existing Twig-based translations?

At this time, there is no supported WPML tool that automatically migrates Twig-detected strings to PHP registrations.

The practical approach would be to identify the existing Twig strings, register them in PHP using stable names/keys, and then recreate or map the translations accordingly.

5. Can the registration code be removed after translations are created?

WPML retrieves translations using the string name and context/domain and falls back to the original string when no translation is available.

Although existing translations may continue to work if the lookup remains unchanged, I would recommend keeping the registration code in place. This ensures the strings remain discoverable and can be properly restored after database migrations, cleanups, or deployments to new environments.

6. What is the recommended approach for performance-sensitive sites?

A common approach is to register strings when they are created, updated, or when relevant administrative screens are loaded, and then perform translation lookups on the frontend.

WPML notes that repeated registration calls are ignored when the string has not changed, and String Translation data is cached, so the overhead is generally limited.

Additional information:

https://wpml.org/documentation/support/translation-for-texts-by-other-plugins-and-themes/

Regarding documentation for this change, none is available. The first announcement mentioning the removal of Twig template support was published here:
WPML 4.8 Will Drop Support for Twig Templates
https://wpml.org/changelog/2025/05/wpml-4-8-will-drop-support-for-twig-templates/