[PR #4089] [MERGED] Include translations in builds #31108

Closed
opened 2026-04-18 07:22:55 -05:00 by GiteaMirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/actualbudget/actual/pull/4089
Author: @jfdoming
Created: 1/4/2025
Status: ✅ Merged
Merged: 1/10/2025
Merged by: @jfdoming

Base: master ← Head: jfdoming/translation-sync


📝 Commits (10+)

  • 1480c9b Pull/push strings via Git instead of via API
  • 1040c78 Schedule workflow instead of running on every commit
  • 8c19a0c Prevent pull requests modifying translations
  • 1499f27 Don't commit translations during the merge freeze
  • 8b8fd3d Add release notes
  • 6604231 Undo rename
  • 8543a50 Don't commit translations nightly, per feedback
  • 31433fa Include translations just-in-time in builds
  • 560b72d Revert "Prevent pull requests modifying translations"
  • 75f19d6 Re-ignore translations

📊 Changes

3 files changed (+96 additions, -29 deletions)

View changed files

📝 .github/actions/setup/action.yml (+19 -2)
📝 .github/workflows/i18n-string-extract-master.yml (+71 -27)
➕ upcoming-release-notes/4089.md (+6 -0)

📄 Description

This PR changes the way we upload new strings to Weblate and adds logic for pulling down translations from Weblate during builds.

Some decisions I made, up for discussion:

  • Commit translations inside actualbudget/actual. The alternative is to use Git submodules (which requires folks to manually update dependencies), manual clones to a specific directory (same problem), or publish an additional npm package (makes pulling edge translations hard). One downside of committing translations like this is that we may get PRs to actualbudget/actual changing the files. I added an action to auto-close these PRs. Revised per discussion below, we now build with translations pulled down just-in-time
  • Schedule workflows instead of running on every commit. I did this to minimize the number of autogenerated commits that get created in each repository AND minimize the amount of downtime in Weblate (we'll lock translations each time we update the strings), with the downside of there being an up-to-24-hour latency in seeing new translations (and hence a minimum 24-hour latency in adding new translated strings).
  • Allow new translations during the merge freeze, but don't include them in the upcoming release. This is maybe the most up for debate here, since allowing translations during the freeze means we could end up with a backlog of breaking changes in translations. However, my thinking is that translations are maybe more robust than the code itself (i.e. a slightly wrong translation could still be intelligible to a native speaker). Let me know your thoughts here! Ideally I'd prefer to avoid locking adding new translations for half the month, since unlike Git where you can open a PR and merge it after the freeze, I don't think you can suggest translations in Weblate when a component is locked. As discussed below, we'll now always clone the latest translations. I updated Weblate to require voting on suggestions instead.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/actualbudget/actual/pull/4089 **Author:** [@jfdoming](https://github.com/jfdoming) **Created:** 1/4/2025 **Status:** ✅ Merged **Merged:** 1/10/2025 **Merged by:** [@jfdoming](https://github.com/jfdoming) **Base:** `master` ← **Head:** `jfdoming/translation-sync` --- ### 📝 Commits (10+) - [`1480c9b`](https://github.com/actualbudget/actual/commit/1480c9b182bccfdd49d9433e24ee7edfc8eead38) Pull/push strings via Git instead of via API - [`1040c78`](https://github.com/actualbudget/actual/commit/1040c78a30e864879e035391031d2945409d134b) Schedule workflow instead of running on every commit - [`8c19a0c`](https://github.com/actualbudget/actual/commit/8c19a0ce136027ca4d289ea9e20e641d9bf54d5d) Prevent pull requests modifying translations - [`1499f27`](https://github.com/actualbudget/actual/commit/1499f2737c13724e3468a4cdae09f3d0b26927ee) Don't commit translations during the merge freeze - [`8b8fd3d`](https://github.com/actualbudget/actual/commit/8b8fd3d58498521872bedb8a3d306457d339c0b5) Add release notes - [`6604231`](https://github.com/actualbudget/actual/commit/660423103e952aed7d9b7950162bd691b6ab4195) Undo rename - [`8543a50`](https://github.com/actualbudget/actual/commit/8543a50527e4d3e3793d112d3574544d9f9aa778) Don't commit translations nightly, per feedback - [`31433fa`](https://github.com/actualbudget/actual/commit/31433fa3353382da2fb338d9268b7c7ecd322fd6) Include translations just-in-time in builds - [`560b72d`](https://github.com/actualbudget/actual/commit/560b72d6841bbe5ca18b400bd830758868bf659c) Revert "Prevent pull requests modifying translations" - [`75f19d6`](https://github.com/actualbudget/actual/commit/75f19d6ed55b618d71a82d56d40a5eafb079aaec) Re-ignore translations ### 📊 Changes **3 files changed** (+96 additions, -29 deletions) <details> <summary>View changed files</summary> 📝 `.github/actions/setup/action.yml` (+19 -2) 📝 `.github/workflows/i18n-string-extract-master.yml` (+71 -27) ➕ `upcoming-release-notes/4089.md` (+6 -0) </details> ### 📄 Description This PR changes the way we upload new strings to Weblate and adds logic for pulling down translations from Weblate during builds. Some decisions I made, up for discussion: - ~~Commit translations inside actualbudget/actual. The alternative is to use Git submodules (which requires folks to manually update dependencies), manual clones to a specific directory (same problem), or publish an additional npm package (makes pulling edge translations hard). One downside of committing translations like this is that we may get PRs to actualbudget/actual changing the files. I added an action to auto-close these PRs.~~ Revised per discussion below, we now build with translations pulled down just-in-time - Schedule workflows instead of running on every commit. I did this to minimize the number of autogenerated commits that get created in each repository AND minimize the amount of downtime in Weblate (we'll lock translations each time we update the strings), with the downside of there being an up-to-24-hour latency in seeing new translations (and hence a minimum 24-hour latency in adding new translated strings). - ~~Allow new translations during the merge freeze, but don't include them in the upcoming release. This is maybe the most up for debate here, since allowing translations during the freeze means we could end up with a backlog of breaking changes in translations. However, my thinking is that translations are maybe more robust than the code itself (i.e. a slightly wrong translation could still be intelligible to a native speaker). Let me know your thoughts here! Ideally I'd prefer to avoid locking adding new translations for half the month, since unlike Git where you can open a PR and merge it after the freeze, I don't think you can suggest translations in Weblate when a component is locked.~~ As discussed below, we'll now always clone the latest translations. I updated Weblate to require voting on suggestions instead. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-18 07:22:55 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#31108