Translation Coverage Insights

[jaysuz]

Hi there! I was wondering whether there is a supported way to get basic insights into the state of the translations in a project.

Using the following locales

// de.json
{
  "A": "B",
  "B": "C"
}
// en.json
{
  "A": "B",
  "C": "D"
}

and the following template,

<template>
  <div>{{ $t('A') }}</div>
  <div>{{ $t('B') }}</div>
  <div>{{ $t('C') }}</div>
</template>

how could I programmatically identify which translation keys used in the project have no representation in the locale files, and what percentage is missing? In our example, this is the information I would want:

+--------+----------+---------+
| locale | coverage | missing |
+--------+----------+---------+
| de     | 66.6%    | 1       |
+--------+----------+---------+
| en     | 66.6%    | 1       |
+--------+----------+---------+

missing keys:
+--------+-----+
| locale | key |
+--------+-----+
| de     | C   |
+--------+-----+
| en     | B   |
+--------+-----+

I know that a warning is logged when vue-i18n encounters a key that has no translation (or fallback translation), but I am thinking more of a static analysis that could easily be performed as e.g. a build pipeline step. It would also be useful to automatically create a .json file holding the missing keys, which then could be handed to translators and later on merged into an existing locale file.

Thanks for any pointers!

[kazupon]

but I am thinking more of a static analysis that could easily be performed as e.g. a build pipeline step.

You might be able to resolve with @intlify/eslint-plugin-vue-i18n using.
https://github.com/intlify/eslint-plugin-vue-i18n

/cc @ota-meshi

It would also be useful to automatically create a .json file holding the missing keys, which then could be handed to translators and later on merged into an existing locale file.

You might be able to resolve with vue-i18n-extract that created by @pixari
https://github.com/pixari/vue-i18n-extract

I’m going to plan to provide type-safe for i18n resources via TypeScript in the near future. (But only JSON at first).
Currently, I'm improving it.
TypeScript will do the type checking of i18n resources, so that key omissions, missing, etc. can be prevented at the TypeScript level.

[jaysuz]

Thanks a lot for your quick reply! I will have a look at the resources you mentioned. It is also interesting to hear that you are looking into the topic of i18n type-safety! Your work is much appreciated.