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

Support
1

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, it comes back.

What’s the best way to accomplish this?

  1. laziness. ↩︎

2 Likes
4

Implementing an integration using our API where you would:

  • Poll Discourse for new overrides (no webhooks)
  • Push new translations from Weblate into your Discourse site.

That’s the preliminary rundown. We’re looking into quantifying the existing limitations, as our current API returns only a fixed amount of translation overrides. Which means we would need to make changes to that API endpoint to make it work.

1 Like
5

Polling seems fine — translation won’t be instant anyway. But does the polling thing need to keep track in some way? It’s nice when it can be stateless…

2 Likes
8

There’s no need to keep track of anything on your site. You should be able to implement it stateless.

  • For polling, you need to send a GET request to the following path on your site:
    /admin/customize/site_texts.json?locale=en&overridden=true&page=0

    Adjust the locale parameter to your needs. The API returns up to 50 results and supports pagination (page parameter).
    The JSON will include { "extras" : { "has_more" : true } } when there are more results.

  • Updating a translation override works by sending a PUT request to the following path:
    /admin/customize/site_texts/<id>

    Replace <id> with the ID of the string you want to translate, e.g. “js.user.username.instructions”.

    The payload of the PUT request must be form data (Content-Type: application/x-www-form-urlencoded; charset=UTF-8) and must include the following attributes:

    • site_text[value]: the translation
    • site_text[locale]: the locale, e.g. “en”

Essentially you need to use the same API calls that the Customize Text admin interface uses.

4 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.