Snowflake localization

We should start localizing the user-facing parts of snowflake. Right now that is just the browser-based proxy, but eventually it will include the WebExtension version.

added anti-censorship-roadmap-august component::circumvention/snowflake l10n owner::arlolra priority::medium resolution::fixed reviewer::cohosh severity::normal snowflake-webextension sponsor::28-can status::closed type::task labels

Moving from Sponsor 19 to Sponsor 30.

Trac:
Sponsor: Sponsor19 to Sponsor30-can

Trac:
Keywords: N/A deleted, snowflake-webextension added

For some of the interface strings (like "Internet Freedom") were translated for Cupcake, and those are available on Transifex if that's useful: https://www.transifex.com/otf/cupcake/misc-strings/

Here's a start on this, https://github.com/keroserene/snowflake/commit/b065410c85f3f5f6184e4ba747c1a9f785a6faea

Trac:
Owner: N/A to arlolra
Status: new to assigned

Trac:
Status: assigned to needs_review

I pushed a poor french translation for the purpose of testing, so maybe just look at the branch, https://github.com/keroserene/snowflake/commits/local

Trac:
Keywords: snowflake deleted, anti-censorship-roadmap-august added

Trac:
Sponsor: Sponsor30-can to Sponsor28-can

Hello!

The json file looks good (if tiny!).

One thing is that Snowflake translations have their own project in Transifex, so I will need saint to give me access to it to manage the translations. I will ask Erin from LocLab to get me access.

oops fail! i mistook cupcake with snowflake :D

This implementation looks good.

• It may be worth doing the /^__MSG_([^_]*)__$/ HTML replacement recursively on every element, to reduce coupling between popup.html and popup.js.
• The popupStatusOn and popupDescOn strings are going to result in displays like "1 clients connected" and "Your snowflake has helped 1 users". Splitting into singular/plural strings isn't enough, because Polish and Russian may need more distinctions depending on how it is phrased ("1 użytkownik", "2 użytkownicy", "5 użytkowników). We may need some custom logic here, something like {{{ const numUsersStringEN = (n) => if (n == 1) { return "1 user"; } else { return String(n) + " users"; }; const NUM_USERS_STRING = new Map([ "en": (n) => numUsersStringEN, "fr": (n) => if (n == 1) { return "1 client"; } else { return String(n) + " clients"; }, "pl": (n) => { if (n == 1) { return "1 użytkownik"; } let d = n % 10; if ((d == 2 || d == 3 || d == 4) && n < 10 && n >= 20) { return String(n) + " użtkownicy"; } return String(n) + " użytkowników"; }, ]); function numUsersString(n) { return (NUM_USERS_STRING.get(chrome.i18n.getUILanguage()) || numUsersStringEN)(n); } ... popup.setStatusText(chrome.i18n.getMessage('popupStatusOn', numUsersString(clients))); }}} An alternative is to rephrase the UI so it's less dependent on grammar: "Number of users helped: 1".

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/PluralRules

I would like to add this file to our translation cycle, but I would like it to be on our repo first.

Do you think you can add proxy/webext/_locales/en/messages.json to https://gitweb.torproject.org/pluggable-transports/snowflake.git/ ?

Also, could the language code be en-US, as it is on the rest of Tor Browser? So we keep consistency.

PS: No need to add the French translation, I will import it on transifex and it may create merge conflicts.

Here's a rebased patch that tries to address all the feedback here, https://github.com/keroserene/snowflake/commit/ecadbe3d869ae3dcdde02d24b6246859621bd34a

It may be worth doing the HTML replacement recursively on every element, to reduce coupling between popup.html and popup.js.

Done

An alternative is to rephrase the UI so it's less dependent on grammar: "Number of users helped: 1".

Took this route with a bit of the suggestions in #31109 (moved)

Do you think you can add proxy/webext/_locales/en/messages.json to ​https://gitweb.torproject.org/pluggable-transports/snowflake.git/ ?

It'll be in there when this patch merges.

Also, could the language code be en-US, as it is on the rest of Tor Browser? So we keep consistency.

I made it en_US (the difference being the underscore) because of the requirement at, https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization#Providing_localized_strings_in__locales

Note the message resolution algorithm at, https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization#Retrieving_message_strings_from_JavaScript

PS: No need to add the French translation, I will import it on transifex and it may create merge conflicts.

They are now removed ... mainly just used for testing.

Trac:
Reviewer: N/A to cohosh

Nice, this looks good to merge what we have right now.

It looks like while the webextension locale is set automatically once we populate the _local folder with translations, but do we need to do something more for the proxy page? Right now it looks like it will only display the English strings: R174

I like the modification from #31109 (moved) to just display that the snowflake is ready if there are zero users.

Trac:
Status: needs_review to merge_ready

Nice, this looks good to merge what we have right now.

Merged as, https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=4e5a50f2b54db62991e4ce3313aa9b7f92a1c573

do we need to do something more for the proxy page?

Yeah, here's a follow up for that, https://github.com/keroserene/snowflake/commit/7bab95d1458859c94513b2e238858eb4f5e1cd69

I would like to add this file to our translation cycle, but I would like it to be on our repo first.

This is now here, https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy/static/_locales/en_US/messages.json

ok! So, the translations for the Snowflake Add on can be fetchs from

https://gitweb.torproject.org/translation.git/log/?h=snowflakeaddon-messages.json

i.e. repo https://git.torproject.org/translation.git branch snowflakeaddon-messages.json

the branch snowflakeaddon-messages.json_completed has only finished translations, but the difference between branches is not that big on this file.

i have added the files in directories per language, let me know if you need me to change the mapping.

Great, thanks!

Some commits to make use of these translations (and the follow up from comment:17) are in, https://github.com/keroserene/snowflake/commits/translation

Trac:
Status: merge_ready to needs_review

please review this little commit for a grammar correction>

https://dip.torproject.org/emmapeel/snowflake/commit/21862faa73c99e9026aeda812dd66531a8f67334

thanks!

Replying to emmapeel:

please review this little commit for a grammar correction>

https://dip.torproject.org/emmapeel/snowflake/commit/21862faa73c99e9026aeda812dd66531a8f67334

Looks good to me. I'm probably using exclamation marks too much ;)

Replying to arlolra:

Great, thanks!

Some commits to make use of these translations (and the follow up from comment:17) are in, https://github.com/keroserene/snowflake/commits/translation

Awesome, this looks good. Just a few clarification questions:

• Does call to writeFileSync with data from availableLangs R43 do the same as copying the translated files in a previous commit: R78? Do we need to remove the copy logic for the proxy if so?
• Do we need to manually update the submodule when there are new translations before they become available?

Does call to writeFileSync with data from availableLangs ​R43 do the same as copying the translated files in a previous commit: ​R78? Do we need to remove the copy logic for the proxy if so?

No, the writeFileSync in R43 is concatenating code to the embed.js file so that the known availableLangs are present there.

The copying in R78 is moving the completed translations to a web accessible place, to be fetched based on the availableLangs.

Do we need to manually update the submodule when there are new translations before they become available?

The translation.git repo will be updated automatically when new translations are completed. However, when we're ready to make a new release, we do need to manually update the submodule beforehand. So, git submodule update --remote, then git add, commit, push. Followed by whatever regular release steps we do.

Replying to arlolra:

Does call to writeFileSync with data from availableLangs ​R43 do the same as copying the translated files in a previous commit: ​R78? Do we need to remove the copy logic for the proxy if so?

No, the writeFileSync in R43 is concatenating code to the embed.js file so that the known availableLangs are present there.

The copying in R78 is moving the completed translations to a web accessible place, to be fetched based on the availableLangs.

Do we need to manually update the submodule when there are new translations before they become available?

The translation.git repo will be updated automatically when new translations are completed. However, when we're ready to make a new release, we do need to manually update the submodule beforehand. So, git submodule update --remote, then git add, commit, push. Followed by whatever regular release steps we do.

Okay nice. Looks ready to merge.

Trac:
Status: needs_review to merge_ready

Okay nice. Looks ready to merge.

These were merged up to, https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=131cf4f8ea0faaa41774e52f5d81878803f45dbc

Looks good to me. I'm probably using exclamation marks too much ;)

That was merged as, https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=ea442141db4cf1451870124d9f1cc8916a82853a

Trac:
Resolution: N/A to fixed
Status: merge_ready to closed

closed

mentioned in issue #31384 (moved)

moved to tpo/anti-censorship/pluggable-transports/snowflake#30310 (closed)