Does `upload_translations` avoid overwriting newer translations?

[henrik]

We currently do something we call "the WTI dance" where we are very careful about not removing translations from WTI that we do not yet have locally.

We like the idea of replacing our current routine with this action, but it's not clear to me from the docs what risks it has in this respect. Could you clarify?

Here is an example scenario:

• Source locale in EN, targets are SV and DE
• Locally, a dev adds a new key "bar" with both EN and SV translations, but not DE
• Now, if we would just blindly wti push and then wti push -t, we risk uploading a file that removes or rolls back some translations (say "foo") that were made between our last wti pull and the time that we wti push -t
• To avoid this, we currently wti pull just before pushing to check that there's nothing new, and we make sure to commit those changes if there is something new.

Does this action handle this kind of scenario robustly?

[edouard]

Hi Henrik,

Great question, and I appreciate you describing the exact scenario — it's a real risk.

The honest answer: the current version of the action doesn't handle this safely by default. A blind wti push followed by wti push -t can indeed overwrite or obsolete translations that exist on WTI but not in your local files. Your "WTI dance" (pull before push) is the right instinct.

We're updating the action to fix this. Here's what's changing:

Safe push for source files

The action will use --merge --ignore-missing flags by default on wti push. This means:

• --merge: WTI merges the uploaded content with existing content instead of replacing it
• --ignore-missing: keys that exist on WTI but are missing from your local file are left alone, not marked as obsolete

In your scenario: the action pushes en.yml with "bar" → "bar" gets added to WTI, the existing "foo" key (which isn't in your local file) is not touched.

Target files are trickier

Your scenario involves developers writing translations directly in locale files, which adds a sync challenge. When you push target files, the uploaded file can overwrite translations that were done on WTI.

The safest workflow with the action is:

1. Developers add keys and source text (EN) in code, commit and push to master
2. The GitHub Action pushes source files to WTI (with safe merge flags) and pulls all translations back into a PR
3. Translation happens on WTI — not in locale files in code

This eliminates the "dance" entirely because the push can never delete anything, and translations flow one way: from WTI into your repo via pull.

If your devs know Swedish and want to contribute translations, they can do it on WTI directly after pushing the key — it takes a few seconds per string and avoids the sync problem entirely. The action will pull those translations back into the repo automatically. We also have a feature called Auto-Translate which would automatically take care of translating SV for you right after pushing the master files, and you would download the SV and DE translations automatically in a PR.

I've been thinking about this problem a lot and in my opinion, changing the workflow so that translations are only done on WTI is the way to eliminate the dance for good.

Summary

What	Risk	After update
Push source file	Can obsolete keys on WTI	Safe (--merge --ignore-missing)
Push target files	Can overwrite translations	Don't push targets; translate on WTI instead
Pull translations	No risk	Works as expected

Let me know if you have follow-up questions. And thanks for the feedback — it's directly shaping how we're building this.

[henrik]

Hi @edouard/Claude 😬

Not finding clear docs on --merge – can you say more about how it merges? I ask because sometimes we remove stuff locally intending for it to be removed remotely, for example. Curious if it'd keep the key or remove it.

I think we've discussed The Dance before and you've said the same, that making the change in the web UI is better. I can see the point… but it still is really convenient as devs to work in our code editor, ofc. Will think more about it though.

[edouard]

Hey Henrik,

The --merge flag is a bit of a misnomer. It doesn’t perform a true merge like Git would. Instead, it preserves existing source text on WTI and only updates or adds new keys from your local file. If a key exists on WTI but isn’t in your local file, it remains untouched.

I’ve been digging into how to handle this more intelligently, like a true three-way merge (comparing your changed file, your baseline, and the WTI version). I've been digging into doing it client side (but it would require language file parsing capabilities, which would make the client quite heavy). I've been looking into doing it server side, but as you can imagine, it’s complex—there are edge cases, conflicts, and scenarios where it might not behave as expected. We’d likely need a dedicated UI for conflict resolution, which is a bigger project.

We’ve talked about “The Dance” before, and I totally get why working in your code editor feels more convenient. But for me the root of the issue is clear: it’s due to having two sources of truth: your local files and WTI. When you push target files, you risk overwriting translations that were updated on WTI, which is why the safest workflow is to only push source files, translate target files on WTI and pull them back into your repo.

If you’re open to it, I’d be happy to set you up on an Enterprise plan trial with AutoTranslate with the GitHub Action. It could actually reduce the workload for your devs: they’d just commit and push to the repo the new keys in English, AI would handle the Swedish translations automatically on WTI. The GitHub Action would then pull everything into a PR. No manual translation or syncing required.

What do you think? Would that workflow feel like an improvement, or are there other pain points we should address?

[henrik]

Hi @edouard. Sorry for not responding sooner.

I do see that merges are complex. All I can say is that they'd also be very convenient DX, but I understand it may not be at the top of the prio list, of course. I think my dream interface for it is no interface – just push our repo to Git and it just happens when conflict-free. That's why GH Actions sounded so promising. (Fairly often, someone changes the local YML files but forgets to change WTI and someone else is inconvenienced.)

And thank you so much for that offer! I'm not sure I understand what that feature consists of. Are you saying that just pushing to the repo (and triggering the GH Action) would cause a new key in the YML files to become a key in WTI?