Add initial .pot file and extract pot generation to a reusable lane

[iangmaia]

Related issues

• Related to the ReleasesV2 migration (see [Tooling] Add Buildkite release pipelines and fastlane lanes for ReleasesV2 #2583)

Proposed Changes

• Extract the .pot file generation logic from the code_freeze lane into a standalone generate_pot_file lane, making it reusable by other lanes (e.g. finalize_release)
• Add the initial i18n/bundle-strings.pot file to version control so it can be used as a baseline for future string extraction

Testing Instructions

• Verify that the generate_pot_file lane can be invoked independently: bundle exec fastlane generate_pot_file

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[sejas]

The code looks good! AFAIU, the .pot file is tracked in Git, so a cron job can use it to update GlotPress. However, I think that file won’t be added back to trunk until the release is completed and the PR is back-merged. @iangmaia , is that right? If so, it will be hard to translate the new strings that are added in the new release.

[AliSoftware]

We do backmerge PRs at different stages of the release process, including:

1. One right after the code-freeze
2. One after each (optional) intermediate beta you might end up adding during the beta-testing phase, if needed
3. One after the release finalization

I expect we generate the updated .pot file during code-freeze, which indeed commit those changes in the release/* branch, but the backmerge from (1) we do at the end of code-freeze should make the new .pot land into trunk early in the process, leaving the whole duration of the beta-testing phase for the new strings to start being translated as soon as the code and string copies are frozen for that release and don't intend to be modified for that release anymore.

This assumes that your beta-testing phase will be long enough for translators to translate new strings, so if your typical beta-testing phase (time between code-freeze and release finalization) lasts 2 weeks (well, ≈ 12 open days) for example that should be plenty enough. If you beta-testing phase is 1 week only, it might or might not be tight depending on the amount of new strings you have to translate and the reactivity of translators, though in most products this is usually still enough. But still good point to be conscious about! 👍

[iangmaia]

we generate the updated .pot file during code-freeze, which indeed commit those changes in the release/* branch, but the backmerge from (1) we do at the end of code-freeze should make the new .pot land into trunk early in the process

🎯 Yep, that's exactly it 👍 So @sejas the GlotPress upload will be from the code freeze. That way, the set of strings being added to a given release is also part of the release.

[wpmobilebot]

📊 Performance Test Results

Comparing dacb487 vs trunk

site-editor

Metric	trunk	dacb487	Diff	Change
load	1428.00 ms	1427.00 ms	-1.00 ms	⚪ 0.0%

site-startup

Metric	trunk	dacb487	Diff	Change
siteCreation	7088.00 ms	7128.00 ms	+40.00 ms	⚪ 0.0%
siteStartup	3939.00 ms	3939.00 ms	0.00 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)