Vandalism in translations

[SomberNight]

I am trying to evaluate the quality of the localisation, to evaluate how to proceed with locking things down.

---

electrum-locale/locale/fr_FR/electrum.po

Lines 174 to 175 in eab55b5

	msgid "&Redo"
	msgstr "Thongchai"

electrum-locale/locale/fr_FR/electrum.po

Lines 1037 to 1038 in eab55b5

	msgid "Cancellation Transaction ID"
	msgstr "edbd3224d120d8304d2194287c4b267707b50b2be46a78409d701327d9d47476\n"

electrum-locale/locale/fa_IR/electrum.po

Lines 252 to 253 in eab55b5

	msgid "- an arbitrary on-chain script, e.g.:"
	msgstr "shah2026"

electrum-locale/locale/ro_RO/electrum.po

Lines 239 to 240 in eab55b5

	msgid "- a Bitcoin address or BIP21 URI"
	msgstr "Română română "

electrum-locale/locale/vi_VN/electrum.po

Lines 174 to 175 in da42e0f

	msgid "Amount to be sent"
	msgstr "10000000000"

^ this one has been there for 8 years

electrum-locale/locale/cs_CZ/electrum.po

Lines 207 to 208 in da42e0f

	msgid "1. Place this paper on a flat and well illuminated surface."
	msgstr "veronikatilke33@seznam.cz"

^ has been there for 2 years, despite Czech being one of the best translated and maintained languages

electrum-locale/locale/es_ES/electrum.po

Lines 355 to 356 in da42e0f

	msgid "Amount received: {}"
	msgstr "cmc6686@gmail.com"

electrum-locale/locale/fa_IR/electrum.po

Lines 147 to 148 in da42e0f

	msgid "&Undo"
	msgstr "Rastakh8888\n"

---

stealing-oriented

electrum-locale/locale/fr_FR/electrum.po

Lines 767 to 768 in eab55b5

	msgid "Avoid spending from used addresses"
	msgstr "bc1qgdl5a90ccznwteha436fn52nekdwuu9ld32n3c"

electrum-locale/locale/ar_SA/electrum.po

Lines 489 to 490 in 7d4bb9d

	msgid "Alert Address"
	msgstr "bc1q393et0s9tv82udvjqfrupyv90s3fqvcfglhrea"

electrum-locale/locale/th_TH/electrum.po

Lines 33 to 34 in 6b07fc2

	msgid "&Addresses"
	msgstr "1Ph4yWX6g7pJk6pgf9fFnQ7fDG8ioCFrLU"

^ been there for 6 years

https://crowdin.com/editor/electrum/68/en-zhcn?view=comfortable&filter=basic&value=0#28992

[SomberNight]

This should help to a limited extent: 7d4bb9d, by making diffs easier to review.

but of course certain types of vandalism, such as inserting propaganda into (say) Chinese strings, only trusted proofreaders could detect

[SomberNight]

We could restrict the set of strings we use from crowdin to the ones "approved" by proofreaders.

In practice currently only Dutch has any meaningful proofreading (see list), but that's perhaps because we have largely ignored this functionality so far. We could start giving proofreader perms to anyone with an established track record. Also, we could perhaps grandfather in the existing translations.

---

Instead of having trusted proofreaders, an alternative is to put the barrier even earlier in the flow: restrict who can become a translator.

Crowdin has a setting for this:

Moderated project joining
Users can become translators for a specific language only after their request is approved by the manager or language coordinator

---

There is also the nuclear option, we could kill the translations and be English-only :/

Or we could default the application to English. Perhaps part of the problem is that we default it to the OS-language. But this would only make a difference if - when changing the language - we warned the user that they will see community-provided translations. Which we cannot really communicate to them as that warning itself would have to be localised >_<

[SomberNight]

The current workflow is untenable. It is not suited for a security-sensitive project at all.

AFAIU, anyone can become a translator by simply registering a crowdin account, and then add translations to any string. Translations can be reddit-style upvoted/downvoted, and the translation with the top votes wins. It's easy to sybil attack, but that is not even necessary: the two bitcoin addresses that I've found (so far?) to have made their way into releases both have 0 votes - they were the only suggested translations for a given string in a given language (French and Arabic, btw), and so they won. I also found a Chinese translation that was just an address which did not get into a release because a single person downvoted it.

Sybil-attacking is also risky: adding a new translation, upvoting, downvoting, all show up in the global project "Activity" timeline. Many new accounts simply upvoting 1 or 2 strings stands out more than adding new translations. The workable attacker strategy so far seems to be trying to blend in.

The last line of defense before getting into a release is supposed to be me or Thomas, when running update.py, which downloads the winning strings from crowdin, and updates this present git repo. However the diffs have been so large that they are not practical to review. Just look at 0870f03. GitHub basically cannot even load it. It is imperative we try to make these diffs reviewable.

• the always-changing line-numbers look to be the primary culprit: this can be fixed by removing the comments, which seems harmless (done in 7d4bb9d)
• the diff showing the new source strings, that don't yet have translations, also creates a lot of noise.
  • Looks like we could just set skipUntranslatedStrings=true?
    • nope, that option does nothing for gettext .po files :/
  • done in bfc8165

[SomberNight]

We could add another post-processing step to update.py that tries to filter out strings that seem to contain bitcoin addresses. Similar to how Bitcoin Core does it for their Transifex community translations (see bitcoin/bitcoin#13374).

However even for the limited scope of catching only bitcoin addresses, there are many ways to trick a regex. For example

• inserting a space:
  bc1 qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
• replacing characters with similar-looking unicode:
  b̈c1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq

And note that in the case of #46, the user who fell for the seemingly malicious translation, actually re-typed a non-selectable bitcoin address manually. In such a case, the translation could easily have used one of the above tricks to counter a regex filter.

---

Stuff we could try to post-process filter out:

• bitcoin addresses
• URLs
• email addresses
• phone numbers??? (how?)
• usernames??? (how? we could filter strings that contain both latin letters and arabic numbers in the same word??)
• blacklist of words?? ("Telegram", "Whatsapp" ?)

EDIT: added some regexes in #49

[AbdussamadA]

A regex to keep out most bitcoin addresses is better than nothing.

[ZenulAbidin]

Regex is not good enough. People will simply find ways around the filter. Why not leverage an AI model via API key, or even better, run a tiny model inside Actions?

Once you find a place to set it up, I created the following prompt which checks a translation and labels it as "Genuine" and "Spam".

It can be thrown in a Github Actions workflow and then every time a commit is merged, you can make a request to the model and then fail the CI job if any translation is spam.

I'm going to paste the prompt below for reference.

You are a binary classifier.

Input format:
msgid: <original English string>
msgstr: <translated string>

Task:
Determine whether msgstr is a legitimate translation of msgid.

Definitions:
- Legitimate translation → preserves meaning of msgid.
- Spam → unrelated text, personal name, joke, profanity, advertisement, political content, trolling, random text, or empty string.

Decision policy:
- If clearly preserves meaning → Genuine
- Otherwise → Spam
- If uncertain → Spam

Output requirements:
- Output exactly one token.
- Allowed outputs: Genuine or Spam
- No punctuation.
- No explanation.
- No extra text.

Input:

[substitute with one line of msgid]
[substitute with  one line of msgstr]

It will need a small python script and a local model that can fit in the Github Actions worker.

Would you guys be interested in such an approach?

[f321x]

@ZenulAbidin yes, a simple regex script doesn't seem enough.
We think of having two checks:

1. regex/pattern matching checks initiated by update.py when we locally pull the translations from crowdin.
2. A Github Action or Cirrus CI script calling a small LLM (like Gemini 3 Flash or Haiku 4.5) through an OpenAI API compatible AI provider to check the diff (new or changed translations) for vandalism when opening a Pull Request to push the new Crowding translations into this repository. If the LLM detects strings with potential vandalism we would manually check and remove those on Crowdin and block the crowdin account. Are you interested in contributing such a CI script to the project?

In addition to this we consider locking down the Crowdin organization to trusted contributors or requiring strings to be proofread a whitelisted proofreader.

[ZenulAbidin]

@f321x Regardless, I do agree with you that the org needs to be locked down and use whitelisting in addition to any technical measure put in place.

[SomberNight]

I do agree with you that the org needs to be locked down and use whitelisting

I think the practical way of locking things down would be to only pull in proofreader-approved strings into this git repo.

• We would keep allowing anyone to join the crowdin project as a translator without barriers,
• but we would start using the proofreader concept and give out proofreader permissions to people that have shown some form of proof of work
  • proof of work: they themselves contributed lots of good translation strings, or github acc with history, bitcointalk acc with long history, or other open source contributions, or meeting us (devs) at multiple conferences, or people we know from irc, etc
    • basically anyone that shows an interest, does not look like a bot, and has a pseudonym with some minimal work attached that was not created too recently
    • e.g. existing accounts who already contributed loads of good strings over several years we could elevate to proofreader permissions without them even asking for it
  • proofreaders can be scoped to a language, or given perms to all languages
  • proofreaders could approve translation suggestions by anyone, and they could also auto-approve their own translation suggestions
    • it is probably not practical to require each translation to go through two people (one Translator suggesting it, and one Proofreader approving it). It would already be a major security improvement even if we allowed Proofreaders to approve their own suggestions.

However note that currently hardly any language is proofread at all. If we only exported approved string right now, that would be equivalent to removing translations from the binaries.
We could post somewhere asking people to step up to be proofreaders... in any case, people reading this are free to ping me anywhere: if they show some proof of work, they will get proofreader permissions.

[AbdussamadA]

• Spam → unrelated text, personal name, joke, profanity, advertisement, political content, trolling, random text, or empty string.

Empty strings are not necessarily spam. Untranslated strings are left empty. So you want to be careful about that.