TO-DO list of converting translation workflow

[Jay-o-Way]

Situation

We encounter a lot of merge problems when Weblate creates a PR to give us translations, because we have all the resource files in the repository, and all of them can be modified during development. Thanks to Visual Studio (editor) applying changes to all those files.

Goal

A clean workflow, where we automate what we can, to prevent merge conflicts, and a smooth and safe way to include translations in the build. In short: remove all translations from the repo, let Weblate handle translations, let CI Build pull them when needed.

Workflow

1. GitHub Repository Setup
   1.1 Keep only English resources in the repo
   1.2 Add .gitignore rule to prevent translated files from being committed
   1.3. Add a Git pre-commit hook to block accidental edits
   1.4. Document the rule: “Developers edit only en-US”
2. Weblate Setup
   2.1. Create Weblate components (see comment below)
   2.2. Set Weblate to track the active development branch
   2.3. Enable authoritative translation mode
   2.4. Disable Weblate PRs
   2.5. Set target languages (Weblate → Project → Languages)
3. CI Pipeline Setup (GitHub Actions or Azure DevOps)
   3.1. Add a step to download translations from Weblate
   3.2. Copy translations into the build folder
   3.3. Build the app with translations included
   3.4. Package and publish
4. Release Workflow
   4.1. When releasing a new version
   4.2. Switch Weblate to the new development branch
5. Optional Enhancements
   • Cache translations in CI
     Avoid hitting Weblate API too often
   • Add a “translation status” badge
   • Add automated checks
     Fail build if English .resw is malformed.
   • Add a local script to pull translations from Weblate
     To be able to test languages locally

💬 Full conversation: https://copilot.microsoft.com/conversations/join/y4WVraaV3yAJ3w59LsULq
📝 Full list: Translation Workflow.pdf
🔗 Link: https://hosted.weblate.org/projects/auto-dark-mode/

[Jay-o-Way]

Note

Since we have different projects with different directory structures for Strings, we need to remember that when setting up Weblate: One Weblate component per project. The good news is: you do NOT need to restructure your SVC project, and the CI pipeline can still inject translations correctly — even if the folder structure differs between projects.

• You do not need to change the SVC project structure
• You create one Weblate component per project
• Each component has its own filemask matching that project’s layout
• CI downloads all translations
• CI copies them into the correct folders
• Build runs exactly as before
• App and SVC both load translations normally
This is exactly how large multi‑project apps handle localization.

For example

App project component

Filemask: AutoDarkModeApp/Strings/*/Resources.resw
Template: AutoDarkModeApp/Strings/en-US/Resources.resw

SVC project component

Filemask: AutoDarkModeSvc/Resources.*.resx
Template: AutoDarkModeSvc/Resources.resx

[Jay-o-Way]

Note

One downside is that - if there are no translations in the online or local repo - it will be more difficult to test (or locally build) with other languages. If you want to, you would have to:

A — Add a local script to pull translations from Weblate (recommended)
B — Keep translations in the repo (not recommended)
C — Hybrid: store translations only in a separate branch

Example script: pull-translations.ps1 (or .psh for Linux/MacOS)

curl -L -o translations.zip "https://weblate.example/api/projects/<project>/download/?format=resw"
unzip translations.zip -d translations/
cp -R translations/AutoDarkModeApp/Strings/* AutoDarkModeApp/Strings/
cp -R translations/AutoDarkModeSvc/* AutoDarkModeSvc/

[Jay-o-Way]

@Spiritreader can you confirm this weblate component can be deleted?