API scope for customized texts

[mattdm (Matthew Miller)]

The use case is syncing with translation – see

What's the best way to programmatically fetch (and write) customized text strings for translations?

I have used the web admin interface to change quite a few Discourse strings. Out of expediency[1] I have ignored the non-English versions. This means, of course, that they’re out of sync. In Fedora, we use Weblate for community-powered translations. (See https://translate.fedoraproject.org/). I’d love to hook this up, ideally so that there’s an entirely automatic workflow where when a string is updated in English via the admin interface, it is sent to Weblate, and when there is a translation, i…

I’d like to provision an API key which can read and write customized texts, but without the power to do anything else.

Although reading all of the overridden strings is probably harmless, it would also be nice to add further restrictions on writes based on a primary language — in my case, English. That would:

1. disallow writes to strings in that language
2. allow writes to strings in other languages only if the primary language string is not default
3. allow reset of strings in non-primary languages to their defaults

(The third rule would allow reset even if the primary language string is customized; this would allow translations to be removed if they need to be for some reason.)

Simply a scope restricting access to only /admin/customize/site_texts would be a nice first pass. However, further (configurable) restrictions on site_text[locale] writes, and even on certain site_text[value]s seems eventually important, because if such a key leaks or is stolen it could be used to deface a site (or insert really sneaky spam links, etc.).