A GitHub action to check i18n/L10n keys and values

i18n-check is a GitHub action used to automate the validation of keys and values of your internationalization and localization processes.

Developed by the activist community, this action is meant to assure that development and i18n/L10n teams are in sync when using JSON based localization processes. The action can be expanded later to work for other file type processes as needed.

Contents

• Conventions
• How it works

Conventions ⇧

activist i18n keys follow the following conventions that are enforced by i18n-check:

• All key base paths should be the file path where the key is used
• If a key is used in more than one file, then the lowest common directory followed by _global is the base path
• Base paths should be followed by a minimally descriptive content reference
  • The formatting of these content references is checked, but nothing more
• Separate base directory paths by periods (.)
• Separate all directory and file name components as well as content references by underscores (_)
• Repeat words in file paths for organization should not be repeated in the key

Note

An example valid key is:

"components.search_bar.CONTENT_REFERENCE" for a key used in components/search/SearchBar.ext

How it works ⇧

You provide i18n-check with the following arguments:

1. src-dir: The path to the directory that has source code to check
2. i18n-dir: The directory path to your i18n files
3. i18n-src: The name of the i18n source file

From there the following checks are ran across your codebase:

4. key_identifiers: Does the source file have keys that don't match the above format or name conventions?
5. unused_keys: Does the source file have keys that are not used in the codebase?
6. non_source_keys: Do the target files have keys that are not in the source file?
7. repeat_values: Does the source file have repeat values that can be combined into a single key?

Each of the above checks is ran in parallel with directions for how to fix the i18n files being provided when errors are raised. Checks can also be disabled in the workflow via options passed in the YAML file.