copy(preferences): "Usage data sharing" toggle + accurate disclosure

[piyalbasu]

TL;DR

Renames the Preferences data-sharing toggle from "Anonymous data sharing" to "Usage data sharing" and replaces its description with an accurate disclosure. The old copy claimed Freighter "will never collect your personal information such as IP address, keys, balance or transaction amounts" — which isn't true.

Both strings are translated into Portuguese as well. The Portuguese copy needs native-speaker sign-off before merge — see the review thread for the rationale and the two wording calls worth a second opinion.

Implementation details (for agents)

Why: the toggle's data actually includes public keys (the seed-derived auth key as user_id, plus a hashed account key), IP address (→ approximate geolocation), and a persistent ID that links a wallet across extension and mobile, sent to our analytics (Amplitude) and crash-reporting (Sentry) providers. "Anonymous" and the "never collects…" line were inaccurate.

New English copy: "Help us improve Freighter by sharing usage, device, and activity data, including your public keys, IP address, and a persistent ID that links your wallet across extension and mobile, with our analytics and crash-reporting providers. You can turn this off at any time. See our Privacy Policy for details."

New Portuguese copy: "Ajude-nos a melhorar o Freighter compartilhando dados de uso, do dispositivo e de atividade — incluindo suas chaves públicas, endereço IP e um ID persistente que vincula sua carteira entre a extensão e o aplicativo móvel — com nossos provedores de análise de dados e de relatórios de falhas. Você pode desativar essa opção a qualquer momento. Consulte nossa Política de Privacidade para mais detalhes." Label: "Compartilhamento de dados de uso". Terminology follows the existing catalog (Política de Privacidade, chave pública, dispositivo, carteira, extensão, and the catalog's o Freighter article convention) rather than introducing new terms.

Changes:

• Preferences/index.tsx: label → Usage data sharing; description → the new single string, replacing a two-string concatenation.
• locales/en/translation.json: added the new label + description keys; removed the two now-false/orphaned description strings and the old label.
• locales/pt/translation.json: same key changes, with Portuguese values.

Verification:

• Catalogs at 841/841 en/pt key parity, 0 keys missing in pt; the count of pt values still identical to their English key is 39, all pre-existing — neither new key is a placeholder.
• The three removed strings are gone from both catalogs with no remaining references anywhere in the repo; no test asserts on the old copy.
• Ran the translation build against this branch and confirmed it is a no-op on both new keys — the parser preserves existing pt values instead of overwriting them with the English default, and the sort positions match what it generates exactly. (Required patching in fix(build): repair yarn build:translations + stop pre-commit hook swallowing its failure #2923 locally, because yarn build:translations is broken on master.)
• npx tsc --noEmit clean; npx prettier --check clean on all changed files.
• New label is 32 chars vs the 33-char label it replaces, so the section title that renders inline with the toggle carries no new overflow risk.

Related / follow-ups:

• fix(build): repair yarn build:translations + stop pre-commit hook swallowing its failure #2923 fixes yarn build:translations, which fails at webpack config load on master, and stops the pre-commit hook from swallowing that failure. Independent of this PR; no file overlap beyond two unrelated sort corrections in the T… block of each catalog.
• If "Privacy Policy" should be a link rather than plain text, that still needs wiring — left as provided.
• The mobile app carries the equivalent toggle; matching copy PR filed separately.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the Preferences analytics toggle with more accurate data-sharing disclosure.

Changes:

• Renames the toggle to “Usage data sharing.”
• Replaces the inaccurate disclosure.
• Removes obsolete English and Portuguese strings.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
Preferences/index.tsx	Updates toggle copy and disclosure.
locales/en/translation.json	Adds new English strings and removes obsolete copy.
locales/pt/translation.json	Removes obsolete Portuguese strings without replacements.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[piyalbasu]

Fixed the catalog issue in a05db85 — and it turned up a second deviation you didn't flag, plus a broken build script.

What was actually wrong: the two new keys were missing from the Portuguese catalog, and both new English keys were dropped into the wrong sort position (they landed where the old Anonymous data sharing key sat). Both are fixed: en and pt are back to 841/841 key parity, and the keys are in sort order.

Partial pushback on "before shipping": the Portuguese values are English placeholders, not translated copy, and I don't think a reviewed pt translation should gate this PR. Placeholders are the repo's existing convention (39 keys already ship that way), and they render identically to the fallbackLng: "en" behavior — so this change doesn't alter what a Portuguese user sees either way. What it fixes is catalog alignment. Blocking on translation would keep the current copy live, and the current copy tells users Freighter "will never collect your personal information such as IP address, keys, balance or transaction amounts" — which is false. Accurate English beats inaccurate Portuguese. Translation stays a tracked follow-up.

Separately: yarn build:translations is broken on master and cannot be run as you suggested. Details below; fixing separately, not in this PR.

---

Detailed explanation (for agents)

Deviation 1 — missing pt keys (as reported). Before this PR the catalogs were at 839/839 parity; the copy commit took en to 841 and left pt at 839. Both keys added to pt with the English string as the value, matching the parser's useKeysAsDefaultValue: true:

freighter/extension/webpack.extension.js

Lines 80 to 90 in a05db85

	options: {
	createOldCatalogs: false,
	locales: LOCALES,
	defaultNamespace: "translation",
	ns: ["translation"],
	output: "src/popup/locales/$LOCALE/$NAMESPACE.json",
	sort: true,
	useKeysAsDefaultValue: true,
	keepRemoved: true,
	removeUnusedKeys: false,
	keySeparator: false,

39 pre-existing pt keys are already English placeholders (Blockaid, Memo, Copied, About verified tokens, …), so this is the established state for untranslated strings, not a new gap. Since fallbackLng is en, the placeholder and the missing-key path produce byte-identical rendered output — the reason to add the keys is so the catalogs match what the parser would emit, i.e. so the build is a no-op rather than a diff.

Deviation 2 — sort placement (not flagged in the review). The copy commit inserted both keys at the old Anonymous data sharing position, inside the An… block, because it was a textual replacement of the key it superseded. With sort: true set, a build would have moved them. Corrected placement, verified against localeCompare ordering of each key's immediate neighbors:

• "Help us improve Freighter by sharing usage, device…" → index 290, after "Help", before "Hidden collectibles"
• "Usage data sharing" → index 749, after "Upload Contract Wasm", before "Use caution when connecting to domains without an SSL certificate."

Same index in both catalogs.

Verification (both catalogs, post-fix):

• Valid JSON; 841 keys each; 0 missing in pt, 0 extra in pt.
• Both new keys present in en and pt; each is localeCompare-ordered w.r.t. its immediate predecessor and successor in both files.
• The three removed strings (Anonymous data sharing, Allow Freighter to collect anonymous information about usage., Freighter will never collect your personal information such as…) are absent from both catalogs and have no remaining references anywhere in the repo — grepped, only hits are the two catalogs and Preferences/index.tsx. No test asserts on the old copy.
• npx tsc --noEmit clean; npx prettier --check clean on all three changed files.

Why the build wasn't used to generate this. yarn build:translations fails at config load on master, independent of this PR:

[webpack-cli] ✖ TypeError: I18nextWebpackPlugin is not a constructor
    at prodConfig (extension/webpack.extension.js:76:13)

i18next-scanner-webpack@1.0.0 is ESM-transpiled and exports the plugin as .default, so the CommonJS require yields { __esModule: true, default: [Function] }:

freighter/extension/webpack.extension.js

Lines 1 to 5 in a05db85

	const { merge } = require("webpack-merge");
	const webpack = require("webpack");
	const I18nextWebpackPlugin = require("i18next-scanner-webpack");
	const { commonConfig } = require("./webpack.common.js");
	const Dotenv = require("dotenv-webpack");

Confirmed the one-line unwrap constructs correctly:

const P = require("i18next-scanner-webpack");
const C = P.default || P;
new C({ async: true, dest: "./", extensions: [".ts", ".tsx"], options: {} });
// => I18nextWebpackPlugin { apply: [Function] }

Consequence worth noting for the locale workflow generally: .husky/pre-commit runs .husky/addTranslations.sh, which calls yarn build:extension:translations and then unconditionally git adds the locales directory. The script has no set -e, so the build failure is swallowed and the hook reports success. Every commit since the plugin version drifted has been silently skipping catalog generation — which is how a hand-edited, out-of-sort key got past the hook in the first place. That's a master bug, out of scope for a copy change; filing separately rather than widening this PR.

Remaining follow-up: reviewed Portuguese translation of the new label + disclosure. Deliberately not machine-translated here — an unreviewed translation of a privacy disclosure risks misstating what data is collected, which is the exact class of error this PR exists to fix.

[piyalbasu]

Build fix filed separately as #2923 — yarn build:translations runs again there, and the pre-commit hook no longer swallows its failure. Its first working run produced only two sort corrections in the T… block of each catalog, so no conflict with this PR's H…/U… edits.

[piyalbasu]

Portuguese translation added in ee44a7b, replacing the English placeholders. Needs native-speaker review — @piyalbasu is lining that up.

Label: Usage data sharing → "Compartilhamento de dados de uso"

Disclosure: → "Ajude-nos a melhorar o Freighter compartilhando dados de uso, do dispositivo e de atividade — incluindo suas chaves públicas, endereço IP e um ID persistente que vincula sua carteira entre a extensão e o aplicativo móvel — com nossos provedores de análise de dados e de relatórios de falhas. Você pode desativar essa opção a qualquer momento. Consulte nossa Política de Privacidade para mais detalhes."

Reviewer: the one call worth a second opinion is the em-dash pair, and the two rendering choices called out below. Everything else follows terminology already in the catalog.

---

Translation rationale + verification (for reviewers)

Terminology taken from the existing catalog, not invented:

English	Portuguese	Precedent in pt/translation.json
Privacy Policy	Política de Privacidade	existing key, used verbatim
public key	chave pública	"Enter issuer public key or contract ID" → "Inserir chave pública do issuer…"
device	dispositivo	"Detect device" → "Detectar dispositivo"
wallet	carteira	"Add a wallet" → "Adicionar uma carteira"
extension	extensão	"…outside of the extension." → "…fora da extensão."
Freighter	o Freighter	"O Freighter nunca pedirá sua chave secreta…" — catalog uses the definite article
data sharing	Compartilhamento de dados	the label this replaces was "Compartilhamento anônimo de dados"

Why the em-dash pair. In the English, with our analytics and crash-reporting providers attaches to sharing — not to the enumerated data. A comma-only Portuguese rendering leaves com nossos provedores stranded far from compartilhando, where it can be misread as scoping only the persistent ID. That would understate what is shared, which is exactly the class of error this PR exists to correct, so I kept the nesting explicit. The catalog already contains one em dash ("…as chaves da sua carteira—guarde-as com segurança…"), though unspaced; I used spaced dashes per standard Brazilian typography for a parenthetical aside.

If you'd rather avoid dashes entirely, the unambiguous alternative is to split into two sentences — same disclosure content, one extra sentence:

"Ajude-nos a melhorar o Freighter compartilhando dados de uso, do dispositivo e de atividade com nossos provedores de análise de dados e de relatórios de falhas. Esses dados incluem suas chaves públicas, endereço IP e um ID persistente que vincula sua carteira entre a extensão e o aplicativo móvel. Você pode desativar essa opção a qualquer momento. Consulte nossa Política de Privacidade para mais detalhes."

Two judgment calls a native speaker should confirm:

1. mobile → o aplicativo móvel. The catalog treats Freighter Mobile as a product name ("Apresentando Freighter Mobile"), but here extension and mobile names the two platforms generically, so I used the common noun. If the team wants the product name, this becomes entre a extensão e o Freighter Mobile.
2. analytics providers → provedores de análise de dados, not provedores de analytics. The catalog does keep some English tech terms (issuer, trustline, popup), so analytics would not be out of place — I chose the Portuguese because this string is consumer-facing privacy copy rather than developer-facing UI.

Layout: the new label is 32 characters against the 33-character label it replaces, so the section title that renders inline with the toggle carries no new overflow risk.

Verification:

• 841/841 en/pt key parity; 0 keys missing in pt; the count of pt values still equal to their English key is back to the 39 pre-existing ones, i.e. these two are no longer placeholders.
• Ran the translation build against this branch (with the fix(build): repair yarn build:translations + stop pre-commit hook swallowing its failure #2923 fix patched in locally, since it is broken on master) and confirmed it is a no-op on both new keys: the parser preserves existing pt values rather than overwriting them with the English default, and the hand-placed sort positions match what it generates byte-for-byte. Its only output was the two unrelated T…-block sort corrections that belong to fix(build): repair yarn build:translations + stop pre-commit hook swallowing its failure #2923, which I reverted to keep this PR scoped.
• npx prettier --check clean.

[github-actions]

PR Preview build is ready: https://github.com/stellar/freighter/releases/tag/untagged-9e93ae5b135b2ed32e21 (SDF collaborators only — install instructions in the release description)