Provide a language switcher menu on BridgeDB

"As a side note, that page always loads in my native language with no way to switch to English -- pages which do this are the worst. In this case it means I can't usefully copy-paste you the exact error messages that I get."

https://lists.torproject.org/pipermail/tor-relays/2018-June/015512.html

added actualpoints::1.4 anti-censorship-roadmap-september component::circumvention/bridgedb owner::phw parent::31279 points::3 priority::medium resolution::fixed reviewer::cohosh s30-o22a3 severity::normal sponsor::30-must status::closed type::enhancement labels

Trac:
Cc: N/A to emmapeel
Type: defect to enhancement

I just had to change the preferences of my Tor Browser to be able to copy a bridge db message

slightly related #15404 (moved)

Trac:
Owner: isis to N/A
Sponsor: N/A to Sponsor19
Status: new to assigned
Points: N/A to 1
Cc: emmapeel to emmapeel, antonela

Trac:
Keywords: N/A deleted, anti-censorship-roadmap-2019 added

Moving from Sponsor 19 to Sponsor 30.

Trac:
Sponsor: Sponsor19 to Sponsor30-must

Trac:
Keywords: anti-censorship-roadmap-2019 deleted, anti-censorship-roadmap added

Trac:
Keywords: anti-censorship-roadmap deleted, anti-censorship-roadmap-september added
Cc: emmapeel, antonela to emmapeel, antonela, irl

Trac:
Parent: N/A to #31289

Ticket #9678 (moved) also proposed a language switcher. The ticket was closed because the work it would have taken to implement this wasn't worth the minor usability benefit we would get out of this. BridgeDB does support a lang argument that allows for language switching, e.g., bridges.torproject.org?lang=de. We may be able to build this feature around this argument.

Trac:
Points: 1 to 3

Trac:
Parent: #31289 to #31279 (closed)

Trac:
Keywords: N/A deleted, s30-o22a3 added

Trac:

Language switcher concept

Here's a patch that implements a language switcher: https://github.com/NullHypothesis/bridgedb/compare/develop...fix/26543

Here's what it looks like:

The patch makes BridgeDB pass all supported languages in an argument to the Mako module (which creates the HTML that's served to the user). Mako then uses a for loop to create the language options in the switcher. The language switcher uses the lang HTTP GET parameter: you can add ?lang=ru to any BridgeDB page, and make it Russian.

Some implementation considerations and questions:

• If a user changes the language, we need to keep track of this change somehow; otherwise it's lost when the user navigates to another page. I wanted to avoid cookies, so I decided to keep state by passing the ?lang=CC argument from page to page. It's not elegant. Is there a better way?
• The patch supports every language for which there is some kind of translation. Some of these languages have few translations. We could only show translations that are, say, 80% complete but I figured that even some translations are better than none.
• Each language in the language switcher is translated to the respective language, i.e., it says "español" instead of "spanish". Is this reasonable?
• The patch treats en, en_US, and en_GB as different languages, which leads to three (unnecessary?) options in the dropdown menu. Is this reasonable? (Note that we cannot just remove any language with a region code in it because Chinese only exists as zh_CN, zh_HK, and zh_TW.)

Trac:
Reviewer: N/A to cohosh
Status: assigned to needs_review

it looks great, phw!

If a user changes the language, we need to keep track of this change somehow; otherwise it's lost when the user navigates to another page. I wanted to avoid cookies, so I decided to keep state by passing the ?lang=CC argument from page to page. It's not elegant. Is there a better way? We are using something similar in tpo.org, but the url looks quite better: torproject.org/ru/about/history/ where /ru/ is the locale.

The patch supports every language for which there is some kind of translation. Some of these languages have few translations. We could only show translations that are, say, 80% complete but I figured that even some translations are better than none. I think is good to show just 80% completed languages. If not, the site looks like broken for non-speakers. Let's have emmapeel in this party so we plan an open a call for translators just for bridge.tpo and gettor.tpo :)

Each language in the language switcher is translated to the respective language, i.e., it says "español" instead of "spanish". Is this reasonable? Yes, it is. We can easily read spanish/english because we share a Latin alphabet. People using another kind of alphabets (arabic, cyrillic, georgian, etc) will look for familiar letters before reading.

The patch treats en, en_US, and en_GB as different languages, which leads to three (unnecessary?) options in the dropdown menu. Is this reasonable? (Note that we cannot just remove any language with a region code in it because Chinese only exists as zh_CN, zh_HK, and zh_TW.)

In this context, maybe you don't have any critical difference between en_US and en_GB, but as you mentioned zh_X glyphs may change. I think we should keep each of them.

@emmapeel, what do you think? are we missing anything?

I left a few comments on the commit but otherwise the code looks good to me. I guess this is probably a needs_revision, to address antonela's comment about the URLs above?

Trac:
Status: needs_review to needs_revision

Trac:
Status: needs_revision to assigned
Owner: N/A to phw

Regarding the languages:

We are usually not supporting en_GB. en and en-US are the same.

With Chinese: zh_CN (simplified Chinese) and zh_TW(Traditional Chinese) cover most of the Chinese speakers, zh_HK is very similar to zh_TW and also we don't have many translators so I feel we can drop it.

After updating the file, there are still this languages to more than 80% translation/review:

• Arabic (ar)
• Catalan (ca)
• Chinese (China) (zh_CN)
• Chinese (Taiwan) (zh_TW)
• Croatian (hr)
• Finnish (fi)
• French (fr)
• German (de)
• Greek (el)
• Hebrew (he)
• Hungarian (hu)
• Irish (ga)
• Italian (it)
• Khmer (km)
• Macedonian (mk)
• Portuguese (Brazil) (pt_BR)
• Portuguese (Portugal) (pt_PT)
• Romanian (ro)
• Spanish (es)
• Spanish (Argentina) (es_AR)
• Swedish (sv)
• Turkish (tr)

Replying to cohosh:

I left a few comments on the commit but otherwise the code looks good to me. I guess this is probably a needs_revision, to address antonela's comment about the URLs above?

Do you mean 623ee47? I don't see any comments on this commit.

Replying to antonela:

If a user changes the language, we need to keep track of this change somehow; otherwise it's lost when the user navigates to another page. I wanted to avoid cookies, so I decided to keep state by passing the ?lang=CC argument from page to page. It's not elegant. Is there a better way? We are using something similar in tpo.org, but the url looks quite better: torproject.org/ru/about/history/ where /ru/ is the locale.

I prefer to leave the URL as it is now. This means that people who are happy with their auto-selected locale won't see any changes to the URL while people who use the language switcher will see the URL change to, say, https://bridges.torproject.org/?lang=pl.

The patch treats en, en_US, and en_GB as different languages, which leads to three (unnecessary?) options in the dropdown menu. Is this reasonable? (Note that we cannot just remove any language with a region code in it because Chinese only exists as zh_CN, zh_HK, and zh_TW.)

In this context, maybe you don't have any critical difference between en_US and en_GB, but as you mentioned zh_X glyphs may change. I think we should keep each of them.

Gotcha, thanks.

Replying to emmapeel:

We are usually not supporting en_GB. en and en-US are the same.

With Chinese: zh_CN (simplified Chinese) and zh_TW(Traditional Chinese) cover most of the Chinese speakers, zh_HK is very similar to zh_TW and also we don't have many translators so I feel we can drop it.

Thanks, that makes sense.

Regarding the languages that are at least 80% complete: these are >=80% reviewed and not >=80% translated, right? If we go down that route, we would be giving up several languages that are (almost) entirely translated but not sufficiently reviewed, like Russian, or Persian. Do we really want this?

Also, the Tier 1 languages are available at https://storm.torproject.org/shared/o7Rh2S9bsMNN7Eh7C9cKaqxR371pR1AmpRxbu--nC34

Replying to phw:

Regarding the languages that are at least 80% complete: these are >=80% reviewed and not >=80% translated, right? If we go down that route, we would be giving up several languages that are (almost) entirely translated but not sufficiently reviewed, like Russian, or Persian. Do we really want this? Unfortunately we dont have many reviewed translations. I was talking about translated strings only.

This is an issue also on the translation platform, because once strings are reviewed, the suggested changes to them are hard to notice and the strings cannot be changed by people without the reviewer status. I am trying to get more strings reviewed but it is unfortunately going slow for many languages. Also we need more trusted reviewers in all languages.

Russian is the second most downloaded locale after English... so I think it will be a pity to lose it.

Let's take care of the "only use >80%-complete languages" issue in #32035 (moved) and only focus on the language switcher in this ticket.

Here's my patch revision: https://github.com/NullHypothesis/bridgedb/compare/e589eaf...4563c2b

Trac:
Status: assigned to needs_review

The code looks good to me!

Trac:
Status: needs_review to merge_ready

I merged the patch and released version 0.9.0.

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

closed

changed time estimate to 24h

added 11h 12m of time spent

mentioned in issue #29450 (moved)

mentioned in issue #31384 (moved)

mentioned in issue #32035 (moved)

mentioned in issue #32134 (moved)

mentioned in issue #31279 (closed)

moved to tpo/anti-censorship/bridgedb#26543 (closed)

mentioned in issue tpo/anti-censorship/bridgedb#32035 (closed)

mentioned in issue tpo/anti-censorship/bridgedb#32134 (closed)