Ensure all strings are valid and don't break builds

[brian-smith-tcril]

@OmarIthawi mentioned an example where invalid strings could break a build here.

what do you think should happen if a po file fails to compile due to Translator writing invalid strings Hi {user} --> Merhaba {kullanci}?

When the strings were checked into the repos directly, this would fail the individual repo CI. With the switch to openedx-translations/openedx-atlas, strings updated in transifex and synced to openedx-translations will not trigger a CI build on any given repo.

We'll want to ensure we don't have strings that break builds checked into openedx-translations, so we should add validation somewhere.

In the same comment, @OmarIthawi mentioned

I'm thinking we should add validation to the https://github.com/openedx/openedx-translations

That seems like a good plan to me

### Tasks
- [ ] Validate JavaScript (React) translation to avoid breaking the build.
- [x] Validate Python (pofile) translations: https://github.com/openedx/openedx-translations/pull/564
- [x] Implement full validation for Python strings like `i18n_tool validate` in addition to `msgfmt` of https://github.com/openedx/openedx-translations/pull/564

[OmarIthawi]

@brian-smith-tcril I looked up for tools to validate JSON translation files, but found none online.

Does it make sense to convert json to po-files and validate them? I'm not sure if there's a two-way conversion between the two format.

I know that Apache superset has a po2json utility, but I haven't tested it.

[brian-smith-tcril]

@OmarIthawi it looks like translate-toolkit could work, it supports converting to and from json.

I was hoping there would be a way to validate without converting out of json by just using the formatjs cli directly, but that doesn't seem to be possible.

I'm not sure if there are any strange edge cases that will trip up the validation with the conversion back and forth, but I think trying out validation with translate-toolkit's json2po and po2json is a reasonable path forward.

[timmc-edx]

It seems that there has been a regression in validation. For example, see this translation where the slot/param name was translated:

https://github.com/openedx/openedx-translations/blob/171142ac6ca8eaabcfea7940d2be935f2264d074/translations/edx-platform/conf/locale/ar/LC_MESSAGES/django.po#L23603-L23605

We have tooling in https://github.com/openedx/i18n-tools that's supposed to catch this sort of thing. It currently picks up about 300 errors in edx-platform alone. Is there some reason this is no longer in use?

[OmarIthawi]

@timmc-edx We have tests in place that is supposed to match i18n-tools, however it sounds like it needs more work.

openedx-translations/scripts/validate_translation_files.py

Lines 32 to 36 in e9a7fe1

	completed_process = subprocess.run(
	['msgfmt', '-v', '--strict', '--check', po_file],
	stdout=subprocess.PIPE,
	stderr=subprocess.PIPE,
	)

I couldn't make i18n-tools work with non-standard file structure such as translations/edx-platform/... therefore I used msgfmt directly.

What do you suggest?

[timmc-edx]

I don't know exactly what msgfmt checks, but I think it's just basic file structure. i18n_tool checks a variety of other things, including whether there are the same parameter slots in the inputs and outputs. You can see all the things it checks here: https://github.com/openedx/i18n-tools/blob/master/i18n/validate.py

I think it would be appropriate to modify that tool to allow different directory structures (or even just expect a different one).

[OmarIthawi]

Yes, it seems like msgfmt is only a part of i18n-tools/blob/master/i18n/validate.py.

I'll keep this issue open for now. Unless someone works on it, I plan to fit within my Open Source contributions late August / early September.