Langchecker is the main repository to update when adding or updating files. There are four different configuration files:
- app/config/locales.inc.php: it contains several lists of locales, like locales supported in mozilla.org, locales only working in Fennec, etc. These lists are then used in the main configuration file to determine which locales are supported for each file. Normally you would need to update this file only when bootstrapping new languages.
- app/config/store_locales.inc.php: this file is generated automatically from external data and tracks locales supported in online stores (Play Store, App Store).
- app/config/websites.inc.php: it contains the configuration for websites (projects) supported in Langchecker.
- app/config/sources.inc.php: it contains the configuration for all files supported in Langchecker.
Langchecker also includes several command line scripts to manage day-to-day operations on supported repositories. For example:
- app/scripts/lang_update: reads the original en-US file, adds missing strings to requested files, reformat localized .lang files. It can also be used to import existing translations from another .lang file.
- app/scripts/mark_active: mark complete files (all strings translated, no errors) as active.
- app/scripts/add_tags: add l10n tags to a file. Some strings in a file can be bound to a tag, allowing to display them in production for mozilla.org only when they’re localized. This script examines if all the strings associated to a specific tag are localized, and adds tags to localized files.
Langchecker's wiki has a full list of the available views, API calls, and command line scripts.
Each project is internally called website, and it’s identified by a numeric index. These are the projects currently supported.
|0||www.mozilla.org||Used to track all files for www.mozilla.org|
|6||engagement||Used for Engagement material, typically snippets.|
|12||appstores||Used to localize material for AppStore (iOS) and Google Play (Android).|
Let’s consider a simple project like Engagement. This is how its definition looks like in the main
6 => [ 'engagement', $repositories['engagement']['local_path'], '', $engagement_locales, $engagement_lang, 'en-US', // source locale $repositories['engagement']['public_path'], 1, 'lang', 'engagement', ['tags'], ],
The structure of each item is:
- Name (used when displaying the website).
- Path to local repository.
- Folder containing locale files.
- Array of supported locale.
- Array of supported files with all associated data.
- Reference locale code.
- URL to public repo (used to create links to files).
- Default priority, used as fallback when files don't specify one.
- Type of files (
- Project name on Pontoon (used for edit links).
- Array of excluded error checks (
For each website there is a list of supported locales, but each file might only use a subset of this list.
For this project, the list of supported files is stored in
$engagement_lang = [ 'ads/ios_android_apr2016.lang' => [ 'supported_locales' => ['de', 'es-ES', 'fr', 'pl'], ], 'ads/ios_android_feb2017.lang' => [ 'deadline' => '2017-02-02', 'supported_locales' => ['zh-HK', 'zh-TW'], ], ...
Flags commonly used are:
- obsolete: the file won’t be displayed in webdashboard at all, and its strings won’t be counted in stats. It’s usually used to mark a file that will be completely deleted later but needs to remain in the repository.
- opt-in: the file was requested only for some locales, but others can decide to opt-in and request the page for translation through Bugzilla.
For more details on the structure of this file, check the [add_new_file.md](documentation to track new files).