Opened 6 months ago

Closed 8 weeks ago

#30310 closed task (fixed)

Snowflake localization

Reported by: cohosh Owned by: arlolra
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords: l10n, snowflake-webextension, anti-censorship-roadmap-august
Cc: emmapeel, dcf, arlolra, cohosh, phw Actual Points:
Parent ID: Points:
Reviewer: cohosh Sponsor: Sponsor28-can

Description

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.

Child Tickets

Change History (25)

comment:1 Changed 5 months ago by phw

Sponsor: Sponsor19Sponsor30-can

Moving from Sponsor 19 to Sponsor 30.

comment:2 Changed 4 months ago by cohosh

Keywords: snowflake-webextension added

comment:3 Changed 3 months ago by saint

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/

comment:4 Changed 3 months ago by arlolra

Owner: set to arlolra
Status: newassigned

comment:5 Changed 3 months ago by arlolra

Status: assignedneeds_review

comment:6 Changed 3 months ago by arlolra

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

comment:7 Changed 3 months ago by gaba

Keywords: anti-censorship-roadmap-august added; snowflake removed

comment:8 Changed 3 months ago by gaba

Sponsor: Sponsor30-canSponsor28-can

comment:9 Changed 3 months ago by emmapeel

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.

comment:10 Changed 3 months ago by emmapeel

oops fail! i mistook cupcake with snowflake :D

comment:11 Changed 3 months ago by dcf

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".

comment:13 Changed 3 months ago by emmapeel

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.

comment:14 Changed 2 months ago by arlolra

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

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.

comment:15 Changed 2 months ago by cohosh

Reviewer: cohosh

comment:16 Changed 2 months ago by cohosh

Status: needs_reviewmerge_ready

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 to just display that the snowflake is ready if there are zero users.

comment:17 Changed 2 months ago by arlolra

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

comment:18 Changed 2 months ago by emmapeel

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.

comment:19 Changed 2 months ago by arlolra

Status: merge_readyneeds_review

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

comment:20 Changed 2 months ago by emmapeel

please review this little commit for a grammar correction>

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

thanks!

comment:21 in reply to:  20 Changed 8 weeks ago by phw

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 ;)

comment:22 in reply to:  19 Changed 8 weeks ago by cohosh

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?

comment:23 Changed 8 weeks ago by 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.

comment:24 in reply to:  23 Changed 8 weeks ago by cohosh

Status: needs_reviewmerge_ready

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.

comment:25 Changed 8 weeks ago by arlolra

Resolution: fixed
Status: merge_readyclosed
Note: See TracTickets for help on using tickets.