Gtranslate update

I am referring to the issues reported by some users in these forum threads:

https://wordpress.org/support/topic/gtranslate-fatal-error-in-wordpress-admin-caused-by-broken-spanish-translation/

https://wordpress.org/support/topic/critical-error-on-many-sites/
https://wordpress.org/support/topic/fatal-error-on-wp-admin-updates-page/

Hi,

The root cause is that sprintf()/printf() in gtranslate.php are called directly on translated strings (esc_html__(...)). When a translation pack is malformed — e.g. the corrupted gtranslate-es_ES pack where %1$s became %1$t (%1$stráfico → %1$tráfico) — PHP 8 throws Uncaught ValueError: Unknown format specifier "t" and the whole site + wp-admin go down (the fatal reported at gtranslate.php:2090).

Deleting the .mo/.po/.l10n.php files works as a workaround, but the plugin stays vulnerable to any broken translation pack. A more robust fix is to make the plugin never let a malformed format string escalate into a fatal error. What I did in our copy:

1. Added three small helper functions (guarded with function_exists): gt_safe_vsprintf($format, array $args), gt_safe_sprintf($format, ...$args) and gt_safe_printf($format, ...$args).
2. gt_safe_vsprintf() runs vsprintf() inside a try/catch (\Throwable). On failure it normalizes every %n$X/%X token to %s, pads/trims the argument list to match, and retries; as a last resort it strips the specifiers. So it can never emit a fatal error.
3. Replaced the direct sprintf(...) / printf(...) calls that wrap translatable strings with gt_safe_sprintf(...) / gt_safe_printf(...) (the admin-notice and settings-page strings, including the one at what was line ~2090).

For a healthy translation the output is byte-for-byte identical to the current code; only a broken format string is caught and degraded gracefully instead of taking the site down.

Would you consider hardening these calls (or the translated format strings) in the next release? Thanks for the plugin!