Troubleshooting WordPress 6.7 Translation Issues with Loco Translate

WordPress 6.7 introduced significant changes to how translations are loaded, shifting to a "Just-in-time" (JIT) system. This update has caused widespread issues for users of the Loco Translate plugin, where custom translations suddenly stop appearing or error messages flood debug logs. This guide explains the core problems and provides the most effective solutions to get your translations working again.

Why This is Happening: The Core Changes in WordPress 6.7

The root cause of these issues lies in two major changes introduced in WordPress 6.7:

1. Just-in-time (JIT) Loading for All: Previously, only some translations were loaded JIT. Now, all plugin and theme translations are loaded this way by default. This change exposed a long-standing limitation in Loco Translate.
2. The System File Requirement: The new JIT loading process has a critical requirement: a translation file must exist in the official WordPress system language directory (wp-content/languages/) for a text domain to be loaded. If no system file is found, the loading process stops completely, preventing Loco Translate from loading your custom files from its "Custom" or "Author" directories.

Furthermore, WordPress 6.7 added new debug notices that flag when a translation is requested too early (before the init action). These notices often point to other plugins or themes as the culprit, but Loco Translate's attempts to work around the problem can sometimes make it appear involved.

Common Symptoms

• Custom translations reverting to English after updating to WordPress 6.7 or later.
• PHP notices in your debug log about translations being loaded "too early" for various text domains (e.g., woocommerce, rank-math, checkout-plugins-stripe-woo).
• Translations only work if a copy exists in both the Loco "Custom" directory and the system directory.
• Seeing error messages like "Unconfigured bundle" or "Translation set not known in Theme" due to changes in how WordPress handles translation paths.

Recommended Solutions

Solution 1: Install System Translation Files (Most Effective Fix)

This is the most reliable solution and aligns with how WordPress now expects translations to work. For each plugin or theme you have custom translations for:

1. Go to Loco Translate → Settings.
2. Find the bundle (plugin/theme) and click its name.
3. Click the "Info" tab.
4. Click the "Install" button next to the "System" location. This will copy the community (GlotPress) translations for that text domain into the correct system directory (wp-content/languages/).

Once the system translation is installed, Loco Translate can properly merge your custom translations on top of it, and the JIT loader will function correctly.

Solution 2: Update Your Plugin and Theme Loading Code

If you are a developer, ensure your plugin or theme loads its text domain correctly. The best practice is to hook into plugins_loaded (for plugins) or after_setup_theme (for themes) and use the standard functions:

// For Plugins
add_action( 'plugins_loaded', 'my_plugin_load_textdomain' );
function my_plugin_load_textdomain() {
    load_plugin_textdomain( 'my-text-domain', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/' );
}

// For Child Themes
add_action( 'after_setup_theme', 'my_child_theme_load_textdomain' );
function my_child_theme_load_textdomain() {
    load_child_theme_textdomain( 'my-text-domain', get_stylesheet_directory() . '/languages' );
}

Solution 3: Update Loco Translate and Enable Its Workaround

Ensure you are running the latest version of Loco Translate (version 2.7 or newer). This version includes a drastic but effective workaround where the plugin forcefully unloads any text domains that were loaded before it ran, allowing it to take control later. This can resolve many "loaded too early" errors. Debug messages related to this ("Unloaded 1 premature text domain") can usually be ignored if your translations are working.

Solution 4: Identify and Fix the True Culprit

The debug notices that mention a specific text domain (e.g., rank-math) often indicate that another plugin is trying to use translations before it should. Disabling other plugins one-by-one can help you identify which one is causing the premature loading. Contacting the support for that specific plugin is the long-term solution, as they need to adjust their code to load translations at the correct time.

Conclusion

The translation issues following WordPress 6.7 are complex and stem from core WordPress changes. While the Loco Translate team has implemented workarounds, the most stable solution is to adopt the new WordPress standard by ensuring system translation files are installed for any text domain you wish to customize. Keeping all plugins, including Loco Translate, updated to their latest versions is also crucial for compatibility.