You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
The "find" CLI command can be used in an automated build process to verify the existence of all required translation keys in all language files. But the languages required to pass that verification, may differ for different build stages.
In an early build stage, only 'en' translations may be required, which are provided by the development team itself. But in a later release stage, translations for all supported languages may be required, with other language translations being provided by some translation agency. Hence the languages that are required to pass the verification, should be configurable (transloco-keys-manager find --langs en)
Currently (version 3.4.1), the "find" command accepts the 'langs' option, but ignores it, and processes all existing json files.
Describe the solution you'd like
If an '--langs' option is given to the "find" CLI command, only matching language files should be processed.
Describe alternatives you've considered
No response
Describe alternatives you've considered
Always generating/extracting all entries for all supported languages works around the problem. But committing those generated/extracted untranslated files/entries to source control, results in unnecessary outgoing changes with a lot of missing key markers that bloat pull request reviews. A workflow that enables us to add only those language files and translation keys to source control, for which actual translations exist, is preferred, but requires us to verify different sets of languages at different build stages.
Additional context
No response
I would like to make a pull request for this feature
Yes 🚀
The text was updated successfully, but these errors were encountered:
Currently, this flag is used only for the generation, as stated:
{
name: 'langs',
alias: 'l',
type: String,
multiple: true,
description: 'The languages files to generate',
},
I think this might be a nice addition.
Generally speaking I think we should separate the flags for each command so it's clearer which can be used where.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe
The "find" CLI command can be used in an automated build process to verify the existence of all required translation keys in all language files. But the languages required to pass that verification, may differ for different build stages.
In an early build stage, only 'en' translations may be required, which are provided by the development team itself. But in a later release stage, translations for all supported languages may be required, with other language translations being provided by some translation agency. Hence the languages that are required to pass the verification, should be configurable (transloco-keys-manager find --langs en)
Currently (version 3.4.1), the "find" command accepts the 'langs' option, but ignores it, and processes all existing json files.
Describe the solution you'd like
If an '--langs' option is given to the "find" CLI command, only matching language files should be processed.
Describe alternatives you've considered
No response
Describe alternatives you've considered
Always generating/extracting all entries for all supported languages works around the problem. But committing those generated/extracted untranslated files/entries to source control, results in unnecessary outgoing changes with a lot of missing key markers that bloat pull request reviews. A workflow that enables us to add only those language files and translation keys to source control, for which actual translations exist, is preferred, but requires us to verify different sets of languages at different build stages.
Additional context
No response
I would like to make a pull request for this feature
Yes 🚀
The text was updated successfully, but these errors were encountered: