Extracting translatable strings from source code.
Here are some notes on Loco Translate's extraction tool and some common pitfalls:
Loco can extract specific text domain strings
Your bundle must declare its correct text domain, or the string extractor won't extract anything. See configuration settings.
Avoid dynamic text domain arguments in source code
Function calls without a literal text domain argument will be ignored,
e.g. Do this:
Force extraction of all text domains
You may use the special text domain value
"*"(asterisk) to force extraction of all strings regardless of their text domain.
This is not the recommended approach, but may get around the dynamic argument problem mentioned above.
Check the file sizes
Loco Translate skips files over a maximum size to avoid memory crashes. This can lead to missed strings, but you will be notified. If the largest file you want to extract from is above your current setting then consider raising it.
Note that extracting templates for the WordPress core requires a setting of over 300K, but we recommend creating core translations by copying existing PO files as they are likely to be correct when installed by the WordPress the updater.
Be aware that our extractor only looks for standard translation functions (such as
__) and is not a full syntax parser.
wp i18n make-pot command. See i18n-command.
Regardless of which tool you use, if you're using
Extracting strings from a file like
dist/prod.js will not work under this system.
This is a characteristic of the WordPress mechanism and is not dictated by Loco Translate. If you have this type of deployment and wish to use
wp_set_script_translations, you will have to ensure somehow that the PO file references point to the script that's actually loaded at run time. One method would be to concatenate sources to an unminified file
dist/prod.js - extract your strings from that - then minify it to