This would be a useful change to limit translation costs/overhead, and also help you learn about how we parse/generate targets from policy_templates.json.

Talk to Julian about which platforms require translated strings - if it is indeed only used for ADMX then you can probably only generate translation requests for the policies that we emit to ADMX.

I just discussed this bug a bit with Kushagra and I am not sure there is much we can do there.

1. All Windows policies need translated resources for ADM[X] templates.
2. All ChromeOS policies which are available for ChromeAD require resources (see 1.)
3. We plan on provider a better substitute for https://www.chromium.org/administrators/policy-list-3 some time this year which hopefully will contain all policies and be localized so we might end up needing any policy text not covered by 1 and 2 and honestly I doubt the list of policies not covered by 1 and 2 is more than a dozen entries long anyhow.

I think the more complex but better option would be to figure out to make the hashing function for string resources be stable to non-translatable changes. E.g. whitespace changes, PH tags name changes etc. This is not a trivial problem but could be a good win. Adding pmarko and ljusten with whom we discussed this previously.

It's not only ADMX that gets translated, but also PLIST_STRINGS and HTML docs.

The source of truth is here:
https://cs.chromium.org/chromium/src/components/policy/tools/template_writers/template_formatter.py?sq=package:chromium&dr=C&l=52
The WriterDescs that take is_per_language=True are translated.

The translated HTML docs are included in the official policy_templates.zip
https://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip
and they contain pretty much every (non-future, non-deprecated?) policy, so I don't think there's much that can be saved.

From my experience a much bigger pain point is - as Julian mentioned - that formatting changes cause a retranslation. For instance, while refactoring grouping, Roman had to jump through hoops to not change indentation of multiline strings, see
https://chromium-review.googlesource.com/c/chromium/src/+/657402.
It should be easy to change the translation string hash to ignore whitespace, but that would cause a one-time retranslation of everything unless the translation team manages to catch that.

Another issue is that some strings (unnecessarily) have line breaks at 80 characters, which confuses translators as they try to recreate the line breaks.

Closing as WontFix because of comments #2 and #3.