Extend translate CLI command to default to all languages and add option for translating only one self-contained system

[PavlovicDzFilip]

Summary & Motivation

Update the translate CLI command to translate all .po files that are missing translations by default.

Add a new --self-contained-system flag (alias -s) that will scope the translations to only translate files for one self-contained system.

Sample usage:

pp translate # Translates all files  
pp translate -s back-office # Translates all files for Back Office  
pp translate -l da-DK # Translates only Danish files  
pp translate -s back-office -l da-DK # Translates Danish files for Back Office

Checklist

• I have added tests, or done manual regression tests
• I have updated the documentation, if necessary

[tjementum]

Hi @PavlovicDzFilip

That is great. I think the --all should be the default. I would also delete the --translate-all and add a -a to be consistent with the conventions.

The most common use case after that would probably be to translate only one self-contained system. E.g., on a build server, we could detect if there are missing translations.

As for the removal of the --language, I've never used it, but it would make sense if you want a Danish person to do the Danish translations and a Dutch person to do the Dutch translations. But I'm okay with the removal.

PS: There are 5 validation errors on your pull-request :)

[PavlovicDzFilip]

Thinking about it from a user perspective, I would love to do a simple pp translate which would translate all the files into all languages. Simple, works, delightful.

This also means we can delete the file selector. It is now shown when the user does not use any option.

The most common use case after that would probably be to translate only one self-contained system. E.g., on a build server, we could detect if there are missing translations.

I don't understand this use case: my assumption is that the developer would want any added keys to be translated, regardless of the self-contained system. The translator is smart enough to use credits only when there is something to translate, so running it across multiple self-contained systems will not increase the costs (if that is what we want to be cautious about?).

With that said, we can pass in a flag --system (-s) to translate all languages from. For example pp translate -s account-management would translate only files found in account-management folder.

I don't think there is a need for such flag. What are your thoughts?

[tjementum]

I don't understand this use case: my assumption is that the developer would want any added keys to be translated, regardless of the self-contained system.

The use case is that I would like to fail the deployment of a self-contained system if translations are missing.

In PlatformPlatform, both Account Management and BackOffice have all translations in English, Danish, and Dutch. When a downstream project built on PlatformPlatform pulls changes using the pull-platformplatform-changes CLI command, they receive all code changes. However, some downstream projects have other languages like German, Spanish, etc., and they would now need to translate missing languages also in Account Management and BackOffice. This might require them to reach out to a German or Spanish colleague.

But if we introduce a rule that blocks releasing one self-contained system if another self-contained system has missing translations, this becomes a problem.

So this is the use case for scoping to a self-contained system. But we would also need a CLI option to just report if translations are missing, that returns true or false.

[tjementum]

Still two small pull request conventions missing.

1. Add the Enhancement label
2. Assign your-self as assignee

I'm not sure if you can see these warnings as an external contributor?

[PavlovicDzFilip]

If a developer pulls the changes using pull-platformplatform-changes, wouldn't the next step be to run translation command to ensure everything is up to date? And the use case you are describing is, if the developer did not run the command and there are missing translations, we want to block the pipelines?

I prefer to translate any missing keys as a part of Pull Request CI pipeline automatically - no developer action required.
That way, the developer experience is great, and there are no half-translated languages.

The downside is when the translation fails for whatever reason - it would block the CI pipeline.
Let's say OpenAI is down, or the API key is not valid anymore. The developer will likely be unable to address the issue without getting someone who has access to those services.

That is a bit outside of scope for this PR, but it is the next step.

Regarding the checks:

• I don't have an option to change the labels or assignee:
  

• I can see the Pull Request Checks after they run. The button to run (and re-run) them is missing, probably due to permission configuration.
  See: https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-public-forks