This step is required to keep translations in the master branch updated.
Branches:
- 0.20 -- bitcoin/bitcoin#18492
- 0.21 -- bitcoin/bitcoin#20058, bitcoin/bitcoin#20256
- 22.x -- accidentally missed
This step is required to keep translations in the master branch updated.
Branches:
Note that we don't generally care about up-to-date translations in master, there is intentionally no transifex resource for master. Strings change too quickly for it to be worth bothering translators. Some strings might even be introduced temporarily and not make a release, for example in the case of a mistaken _("…"). Translators are only involved after the soft string freeze. This is 2022-02-02 for 23.0 (see #22969).
That said, doing a one-time pull of translations from transifex before forking the branch doesn't hurt.
35 | @@ -36,7 +36,8 @@ Release Process 36 | - This update should be reviewed with a reindex-chainstate with assumevalid=0 to catch any defect 37 | that causes rejection of blocks in the past history. 38 | - Clear the release notes and move them to the wiki (see "Write the release notes" below). 39 | -- Translations on Transifex 40 | +- Translations on Transifex: 41 | + - Pull translations from Transifex into the master branch. 42 | - Create [a new resource](https://www.transifex.com/bitcoin/bitcoin/content/) named after the major version with the slug `[bitcoin.qt-translation-<RRR>x]`, where `RRR` is the major branch number padded with zeros. Use `src/qt/locale/bitcoin_en.xlf` to create it.
It's unrelated to this PR, but I'm confused by this order of steps, or whether this step and below should be listed in Before branch-off. We do them at the time of the translations freeze, which is roughly a month 'before branchoff'. Also e.g. "Change the auto-update URL for the resource to master" makes no sense to do immediately before creating the branch anyway.
I guess "before branch-off" lists all the things that need to be done before branch off, irrespective of how long before it. Which is fine but also easy to read differently.
That said, there's no hurt in adding this so going to merge ACK 6e328ff8d044ac0d0b6e10e842b2b0ad7503f296