WordPress uses GlotPress for managing translations, which is built on top of the
gettext standard. On the other hand,
Nuxt (and most JS-based i18n libraries) use
JSON for managing
translations. This disconnect means that Openverse translations must convert
from JSON to POT and back again. Hence there is quite a bit of scaffolding
This pipeline deals with how translations strings are extracted from the frontend application and provided to GlotPress for translation.
Create a POT file from the
GlotPress presents the strings, fuzzy translations and other helpful context to translators in a web UI to help them provide a translation.
This pipeline deals with how translations are retrieved from GlotPress, processed and loaded into Nuxt via the Nuxt i18n module.
Parse and extract the list of all locales from GlotPress’s PHP source code. Then narrow down the list to locales available in the WP GlotPress instance and populate their coverage percentage from the GlotPress stats.
The output is written to
Download all translations from GlotPress as JED 1.x JSON files. The flattened JED 1.x (derived from the flattened POT files) files are converted back into the nested JSON as expected by Nuxt i18n.
This script downloads all available translations in bulk as a ZIP file and then extracts JSON files from the ZIP file. This prevents excessive calls to GlotPress, which can be throttled and cause some locales to be missed.
Separate the locales into three groups based on the JSON files emitted by
translated: JSON file is present with mappings, written to
untranslated: JSON file is present but empty, written to both
invalid: JSON file is not present, written to
Pass the list of valid locales (along with extra fields) into the Nuxt i18n module. This is configured in the Nuxt configuration file,
Pass the fallback locale mappings to the underlying Vue i18n plugin. This is configured in the plugin configuration file,