Opened 18 months ago

Closed 2 months ago

#26543 closed enhancement (fixed)

Provide a language switcher menu on BridgeDB

Reported by: teor Owned by: phw
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Normal Keywords: anti-censorship-roadmap-september, s30-o22a3
Cc: emmapeel, antonela, irl Actual Points: 1.4
Parent ID: #31279 Points: 3
Reviewer: cohosh Sponsor: Sponsor30-must

Description

"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

Child Tickets

Attachments (1)

switcher.jpg (96.4 KB) - added by phw 2 months ago.
Language switcher concept

Download all attachments as: .zip

Change History (28)

comment:1 Changed 13 months ago by emmapeel

Cc: emmapeel added
Type: defectenhancement

comment:2 Changed 13 months ago by emmapeel

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

comment:3 Changed 13 months ago by emmapeel

slightly related #15404

comment:4 Changed 11 months ago by gaba

Cc: antonela added
Owner: isis deleted
Points: 1
Sponsor: Sponsor19
Status: newassigned

comment:5 Changed 7 months ago by gaba

Keywords: anti-censorship-roadmap-2019 added

comment:6 Changed 6 months ago by phw

Sponsor: Sponsor19Sponsor30-must

Moving from Sponsor 19 to Sponsor 30.

comment:7 Changed 6 months ago by gaba

Keywords: anti-censorship-roadmap added; anti-censorship-roadmap-2019 removed

comment:8 Changed 5 months ago by gaba

Cc: irl added
Keywords: anti-censorship-roadmap-september added; anti-censorship-roadmap removed

comment:9 Changed 5 months ago by gaba

Parent ID: #31289

comment:10 Changed 3 months ago by phw

Points: 13

Ticket #9678 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.

comment:11 Changed 3 months ago by gaba

Parent ID: #31289#31279

comment:12 Changed 3 months ago by gaba

Keywords: s30-o22a3 added

Changed 2 months ago by phw

Attachment: switcher.jpg added

Language switcher concept

comment:13 Changed 2 months ago by phw

Reviewer: cohosh
Status: assignedneeds_review

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

Here's what it looks like:

Language switcher concept

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

comment:14 Changed 2 months ago by antonela

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?

comment:15 Changed 2 months ago by cohosh

Status: needs_reviewneeds_revision

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?

comment:16 Changed 2 months ago by phw

Owner: set to phw
Status: needs_revisionassigned

comment:17 Changed 2 months ago by emmapeel

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.

comment:18 Changed 2 months ago by emmapeel

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)

comment:19 in reply to:  15 Changed 2 months ago by phw

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.

comment:20 in reply to:  14 Changed 2 months ago by phw

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.

comment:21 in reply to:  17 ; Changed 2 months ago by phw

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?

comment:23 in reply to:  21 Changed 2 months ago by emmapeel

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.

comment:24 Changed 2 months ago by phw

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

comment:25 Changed 2 months ago by phw

Status: assignedneeds_review

comment:26 Changed 2 months ago by cohosh

Status: needs_reviewmerge_ready

The code looks good to me!

comment:27 Changed 2 months ago by phw

Actual Points: 1.4
Resolution: fixed
Status: merge_readyclosed

I merged the patch and released version 0.9.0.

Note: See TracTickets for help on using tickets.