Escopo da API para textos personalizados

[mattdm (Matthew Miller)]

O caso de uso é a sincronização com a tradução – veja

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…

Gostaria de provisionar uma chave de API que possa ler e escrever textos personalizados, mas sem o poder de fazer qualquer outra coisa.
Embora a leitura de todas as strings substituídas seja provavelmente inofensiva, também seria bom adicionar restrições adicionais às gravações com base em um idioma principal — no meu caso, o inglês. Isso:

1. impediria gravações em strings nesse idioma
2. permitiria gravações em strings em outros idiomas somente se a string no idioma principal não for padrão
3. permitiria a redefinição de strings em idiomas não primários para seus padrões
   (A terceira regra permitiria a redefinição mesmo que a string no idioma principal seja personalizada; isso permitiria que as traduções fossem removidas se necessário por algum motivo.)
   Simplesmente um escopo restringindo o acesso apenas a /admin/customize/site_texts seria um bom primeiro passo. No entanto, restrições adicionais (configuráveis) em gravações de site_text[locale] e até mesmo em certos site_text[value] parecem eventualmente importantes, porque se tal chave vazar ou for roubada, ela pode ser usada para desfigurar um site (ou inserir links de spam muito sorrateiros, etc.).