Hello Toolset Support,
I would like to report what appears to be a compatibility/regression issue involving Toolset Blocks and WPML String Translation.
Our site uses Japanese names for Toolset Views and taxonomy filters. After updating Toolset Blocks to 1.6.26, WPML began generating a large number of unusually named files in:
/wp-content/languages/wpml/queue/
The filenames/domains looked like:
View %e3%...
View %e5%...
View %e7%...
These appear to be Japanese View names encoded with percent encoding.
Initially, this caused repeated warnings in the WPML Translation Dashboard:
unlink(...): File name too long
The warnings originated from:
wpml-string-translation/StringTranslation/Infrastructure/StringGettext/Command/DeletePendingStringsPhpCommand.php
Deleting/recreating the WPML queue directory temporarily restored the Translation Dashboard, but the problem immediately began to recur when Toolset Views were rendered.
More importantly, we then received fatal errors such as:
Uncaught ArgumentCountError: 50 arguments are required, 2 given
at:
/wp-content/plugins/wpml-string-translation/classes/translations-file-scan/wpml-st-translations-file-registration.php:88
The relevant part of the stack trace is:
WPML_ST_Translations_File_Registration->save_file_info('View %e5%8b%95%...', 'View %e5%8b%95%...', ...)
followed by:
load_textdomain('View %e5%8b%95%...', ...)
and eventually:
WPML\ST\TranslateWpmlString->translateByMOFile(...)
The call appears to originate from Toolset Blocks:
/wp-content/plugins/toolset-blocks/embedded/inc/wpv.class.php
and:
/wp-content/plugins/toolset-blocks/embedded/inc/filters/wpv-filter-category-embedded.php
The relevant stack trace includes:
wpv_translate(...)
→ icl_t('View %e5%8b%95%...', 'wpv-facts-categ...', '%%NAME%%')
The affected View contains taxonomy filters created with Toolset, including multiple Japanese taxonomy terms.
Environment
Toolset Blocks: 1.6.26
WPML Multilingual CMS: 4.9.7
WPML String Translation: 3.5.4
PHP: 8.3.30
WordPress site language: Japanese
Theme: Blocksy
Important observation
The files with names beginning with View %... started appearing in the WPML queue around the time of the Toolset Blocks update.
As a troubleshooting test, I:
Backed up the site.
Deactivated and removed Toolset Blocks 1.6.26.
Installed Toolset Blocks 1.6.21.
Cleared/recreated /wp-content/languages/wpml/queue/.
Loaded the affected Toolset Views and taxonomy filters again.
So far, the problem has not reproduced with Toolset Blocks 1.6.21.
The Views and taxonomy filters are currently functioning normally, and the WPML Translation Dashboard is also functioning normally.
This strongly suggests that a change between Toolset Blocks 1.6.21 and 1.6.26 may be causing Japanese View names to be passed to WPML as dynamically generated text domains such as:
View %e5%8b%95%...
WPML String Translation subsequently appears to treat these strings as translation domains/file names. The percent-encoded characters then appear to cause both excessively long queue filenames and sprintf() ArgumentCountError exceptions.
Could you please investigate whether this is a regression in Toolset Blocks, particularly in the interaction between wpv_translate(), icl_t(), and WPML String Translation when a View has a non-Latin/Japanese name?
I can provide the complete stack trace, screenshots of the generated queue files, and additional site/debug information if needed.
For now, we are keeping Toolset Blocks at 1.6.21 because 1.6.26 causes critical errors on the production site.
Thank you.
