Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:09:58Zhttps://gitlab.torproject.org/legacy/trac/-/issues/22395find a way to present the comment threading more intuitively2020-06-13T17:09:58ZRoger Dingledinefind a way to present the comment threading more intuitivelyCheck out
https://blog.torproject.org/blog/did-fbi-pay-university-attack-tor-users#comments
then scroll down and try to figure out which comment is replying to which comment.
The hierarchy is still basically flat, and you have to count ...Check out
https://blog.torproject.org/blog/did-fbi-pay-university-attack-tor-users#comments
then scroll down and try to figure out which comment is replying to which comment.
The hierarchy is still basically flat, and you have to count the number of vertical lines to the left of the comment to try to figure out what's going on.
I think it could be improved by indenting comments as a function of where they are in the nested hierarchy.
But that's not the only possible way. I suspect there are other, better, options too.Antonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22392Should we remove or compress the left column on the blog?2020-06-13T17:09:57ZRoger DingledineShould we remove or compress the left column on the blog?We have a new blog (yay), and it comes with a new template (mostly yay).
The engineers among us have been staring at the left of the three columns on the blog, and wondering if that is the best amount of whitespace to use, while smushin...We have a new blog (yay), and it comes with a new template (mostly yay).
The engineers among us have been staring at the left of the three columns on the blog, and wondering if that is the best amount of whitespace to use, while smushing all the content into the middle column.
See e.g.
https://blog.torproject.org/blog/tor-0306-released-new-series-stable
and scroll down a bit. Notice how you're now reading a narrow column of text, with plentiful whitespace on either side of it.
Maybe whoever designed this layout had a big screen resolution, and it worked better there.
I have no clue how this looks on mobile, but ... ok, actually I went to go check, and on ios safari it just shows me the middle column, and it pretends those left and right columns aren't there. Lucky mobile users. :)
I am adding the ux-team keyword in hopes that they can help us move forward. I know that "hey user experience people, can you help with layout, that's the same thing right" must drive you crazy, and I apologize in advance, but you're still our best hope here. :)Antonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22335Please remove "The" from the blog title2020-06-13T17:09:51ZteorPlease remove "The" from the blog titleThe current title is: "The Tor Blog | The Tor Project Blog"
"The" doesn't add any useful information. And it makes tab names hard to read when I have many tabs open.
I suggest we remove both instances of "The".
And maybe we want to thi...The current title is: "The Tor Blog | The Tor Project Blog"
"The" doesn't add any useful information. And it makes tab names hard to read when I have many tabs open.
I suggest we remove both instances of "The".
And maybe we want to think about whether repeating "Tor" and "Blog" is useful too.HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/22334Missing top-right links in blog2020-06-13T17:09:50ZteorMissing top-right links in blogThere are 9 links in the top right of https://www.torproject.org/ , and the new blog only has 2 in the top center left (and the blog link in the top right).
Did we deliberately remove:
* Documentation
* Press
* Contact
* Download
* Volu...There are 9 links in the top right of https://www.torproject.org/ , and the new blog only has 2 in the top center left (and the blog link in the top right).
Did we deliberately remove:
* Documentation
* Press
* Contact
* Download
* Volunteer
I'd like to put Download back if we can, not sure about the other ones.HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/22266gather info on jump-to-80% issues2020-06-13T17:43:43ZTaylor Yugather info on jump-to-80% issuesThis ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the ...This ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the logs and the control connection jumps from 0% to 80% almost immediately. This is misleading and causes user frustration, as reported by Linda's study.
When bootstrapping with existing directory information, we should rescale the progress numbers so they advance on something resembling a linear time scale, which is probably closer to what users expect to see.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22241Implement a proper wiki (just as Mozilla does)2020-06-13T17:24:43ZTracImplement a proper wiki (just as Mozilla does)Just an idea that I got: "Wiki" articles are available in trac, which makes it less likely to be seen https://trac.torproject.org/projects/tor/wiki/TitleIndex
Mozilla for example has its own wiki portal https://wiki.mozilla.org/Main_Pa...Just an idea that I got: "Wiki" articles are available in trac, which makes it less likely to be seen https://trac.torproject.org/projects/tor/wiki/TitleIndex
Mozilla for example has its own wiki portal https://wiki.mozilla.org/Main_Page (and it uses MediaWiki which makes it much more attractive, and has the look of a wiki)
(Of course, already existing articles may be ported to that new portal)
**Trac**:
**Username**: blockflareWebsiteV3HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/22201Wireframes for community.torproject.org subpages2020-06-13T17:24:42ZLinda LeeWireframes for community.torproject.org subpages= Objective =
Design how to lay out the content for dev.torproject.org's subpages:
* __community.torproject.org/volunteer__: a page that encourages volunteers, tells what it's like, and houses the community council, and behavioral gu...= Objective =
Design how to lay out the content for dev.torproject.org's subpages:
* __community.torproject.org/volunteer__: a page that encourages volunteers, tells what it's like, and houses the community council, and behavioral guidelines materials.
* __community.torproject.org/outreach__: a page hosting all images, videos, audio, request for pamphlets, worksheets, papers, tutorials, etc. related to community. I think a way to organize all of this would be the main challenge.
* __community.torproject.org/help__: To be completely honest with you, I don't know how I feel about a call for help page because it has to constantly be maintained. Plus, I think that the better thing to do is to just get in contact with the community team lead right away and they can just inform the people of what needs to be done. So instead of listing a bunch of tasks, let's design something that gets the user to get in contact with the community team lead in the least frictionless way.
= Definitions =
* wireframes are rough sketches that illustrate the general idea of the design. A wireframe lets you talk about content placement and layout while abstracting finer details such as font, color, styling, and other considerations.
# Methodology
Antonela will independently sketch her best first design of the sub pages, according to previous sitemapping and content organization work. Linda will then review her design, make comments, and Antonela will iterate once before counting it done for this ticket. But this will just result in the initial designs, and these designs will be iterated on some more with feedback from stakeholders.
# Results
_Linda will place wireframes here once the task is complete. _website redesignAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22200Wireframes for support.torproject.org subpages2020-12-11T15:56:14ZLinda LeeWireframes for support.torproject.org subpages= Objective =
Design how to lay out the content for dev.torproject.org's subpages:
The support page is a bit different, since we plan for all the support subpages look the same, with different content in the middle. I think that the ...= Objective =
Design how to lay out the content for dev.torproject.org's subpages:
The support page is a bit different, since we plan for all the support subpages look the same, with different content in the middle. I think that the work I'd be doing for the subpages is to 1) make wireframes that explains what that really means 2) make wireframes that shows the interactivity between page components and 3) decide what is going to go on the sidebar as topics, and to organize all the information in a way that makes sense.
= Definitions =
* wireframes are rough sketches that illustrate the general idea of the design. A wireframe lets you talk about content placement and layout while abstracting finer details such as font, color, styling, and other considerations.
# Methodology
Linda will independently sketch her best first design of the sub pages, according to previous sitemapping and content organization work. Antonela will then review her design, make comments, and Linda will iterate once before counting it done for this ticket. But this will just result in the initial designs, and these designs will be iterated on some more with feedback from stakeholders.
# Results
_Linda will place wireframes here once the task is complete. _website redesignIsabela FernandesIsabela Fernandeshttps://gitlab.torproject.org/legacy/trac/-/issues/22199Wireframes for dev.torproject.org subpages2020-12-11T15:56:15ZLinda LeeWireframes for dev.torproject.org subpages= Objective =
Design how to lay out the content for dev.torproject.org's subpages:
* __dev.torproject.org/teams__: putting the team roadmap and projects for each team is actually pretty intense to update/maintain at the website level...= Objective =
Design how to lay out the content for dev.torproject.org's subpages:
* __dev.torproject.org/teams__: putting the team roadmap and projects for each team is actually pretty intense to update/maintain at the website level. Developers also didn't want this, so I think this page can just include detailed descriptions of the teams.
* __dev.torproject.org/getting-started__: we link to git, irc, and trac on the dev landing banner. I think this page can explain the technology that we use to do the work, organizational-wide. I would like for this to have two functions 1) give a basic overview of what the thing does (i.e. "we use IRC for almost all live communication") 2) link to external links to help them get started (i.e. a tutorial on IRC from irc people) and 3) why we use it (i.e. "Although it's behind the times, we choose it because of these security properties.").
* __dev.torproject.org/resources__: a page that houses links to all the important manuals and tutorials here. We're not going to create new tutorials or go through the trouble of updating it on the website if they update their link, etc. What's important for this page is that there might be lots and lots of links here, so we should have it organized in a way that people can easily find what they need.
= Definitions =
* wireframes are rough sketches that illustrate the general idea of the design. A wireframe lets you talk about content placement and layout while abstracting finer details such as font, color, styling, and other considerations.
# Methodology
Antonela will independently sketch her best first design of the sub pages, according to previous sitemapping and content organization work. Linda will then review her design, make comments, and Antonela will iterate once before counting it done for this ticket. But this will just result in the initial designs, and these designs will be iterated on some more with feedback from stakeholders.
# Results
_Linda will place wireframes here once the task is complete. _website redesignAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22198Wireframes for torproject.org subpages2020-12-11T15:56:14ZLinda LeeWireframes for torproject.org subpages= Objective =
Design how to lay out the content for torproject.org's subpages:
* __torproject.org/download__: a page dedicated to just downloading Tor Browser, similar to https://www.mozilla.org/en-US/firefox/new/, but with more inst...= Objective =
Design how to lay out the content for torproject.org's subpages:
* __torproject.org/download__: a page dedicated to just downloading Tor Browser, similar to https://www.mozilla.org/en-US/firefox/new/, but with more instructions since there are failure cases.
* __torproject.org/about__: a page with all the institutional stuff--mission statement, disclaimers, tax statements, employee numbers, etc.
* __torproject.org/people__: a page with all the people in tor. The board, employees, sponsors, and any relevant people.
* __torproject.org/press__: a list of all the press we got, a huge list of stuff and I need to organize all the articles.
* __torproject.org/contact__: a page that shows various contact points (executive director, head of board, hr, support, etc.) for Tor, with the aim to list everyone contactable here (kind of like a public address book).
= Definitions =
* wireframes are rough sketches that illustrate the general idea of the design. A wireframe lets you talk about content placement and layout while abstracting finer details such as font, color, styling, and other considerations.
# Methodology
Linda will independently sketch her best first design of the sub pages, according to previous sitemapping and content organization work. Antonela will then review her design, make comments, and Linda will iterate once before counting it done for this ticket. But this will just result in the initial designs, and these designs will be iterated on some more with feedback from stakeholders.
# Results
_Linda will place wireframes here once the task is complete. _website redesignLinda LeeLinda Leehttps://gitlab.torproject.org/legacy/trac/-/issues/22163Make it more obvious how to report security related bugs2020-06-13T17:24:40ZGeorg KoppenMake it more obvious how to report security related bugsWe had a report about a bug reporter getting different (and partly) conflicting advice on how to report security sensitive bugs. The canonical way of doing so is mailing to tor-security@lists.torproject.org. However, that seems to be not...We had a report about a bug reporter getting different (and partly) conflicting advice on how to report security sensitive bugs. The canonical way of doing so is mailing to tor-security@lists.torproject.org. However, that seems to be not found easily. We should change that on our website.HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/22121old tasks (tor project website redesign)2020-06-13T17:24:38ZLinda Leeold tasks (tor project website redesign)old tasks related to wireframes.old tasks related to wireframes.website redesignLinda LeeLinda Leehttps://gitlab.torproject.org/legacy/trac/-/issues/22120Research tasks (tor project website redesign)2020-06-13T17:24:38ZLinda LeeResearch tasks (tor project website redesign)This ticket groups together the work we did to prepare for designing torproject.org and its portals.This ticket groups together the work we did to prepare for designing torproject.org and its portals.Linda LeeLinda Leehttps://gitlab.torproject.org/legacy/trac/-/issues/22077Wireframes for the landing pages of torproject.org portals2020-06-13T17:24:37ZLinda LeeWireframes for the landing pages of torproject.org portals= Objective =
Design how to lay out the most important content for torproject.org, dev.torproject.org, support.torproject.org, and community.torproject.org.
= Definitions =
* wireframes are rough sketches that illustrate the gene...= Objective =
Design how to lay out the most important content for torproject.org, dev.torproject.org, support.torproject.org, and community.torproject.org.
= Definitions =
* wireframes are rough sketches that illustrate the general idea of the design. A wireframe lets you talk about content placement and layout while abstracting finer details such as font, color, styling, and other considerations.
* landing pages are the official terms for the "front page" of a website. If you visit torproject.org, the first page that you see is the landing page.
* portals refer to the different subsites mentioned above (dev, support, community)
# Methodology
Linda and Antonela will independently sketch their best first design of the four landing pages, limiting themselves to including only the content deemed important for the front page on #21950. They will compare their designs, talk about why they made the design choices that they did, and then collaboratively work on a final design from those two independent designs.
# Results
We have the first iteration of the landing pages. We'll reach out for feedback, update them, and repeat this process a couple times.
![INITIAL-tpo-landing.png,500px](uploads/INITIAL-tpo-landing.png,500px)
![INITIAL-dev-landing.png,500px](uploads/INITIAL-dev-landing.png,500px)
![INITIAL-support-landing.png,500px](uploads/INITIAL-support-landing.png,500px)
![INITIAL-community-landing.png,500px](uploads/INITIAL-community-landing.png,500px)
You can find the the [sketch file](https://trac.torproject.org/projects/tor/attachment/ticket/22077/INITIAL-tpo-landing-page-wireframes.sketch) and the [pdf of the pages](https://trac.torproject.org/projects/tor/attachment/ticket/22077/INITIAL-tpo-landing-page-wireframes.pdf) here.Linda LeeLinda Leehttps://gitlab.torproject.org/legacy/trac/-/issues/21952Onion-location: increasing the use of onion services through automatic redire...2021-03-22T16:56:26ZLinda LeeOnion-location: increasing the use of onion services through automatic redirects and aliasing= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they ...= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they want more people to visit onion sites and they will do so if it is painless to them). But when users were redirected automatically to an onion site, they freaked out about it because they didn't know what happened, didn't know what onion sites were, and the "https" was dropped.
asn and dgoulet also were trying to find a solution to make onion sites more accessible to use. Specifically, onion addresses are quite long and random-ish, making them hard to remember and hard to type. There were many solutions discussed casually to try and resolve this, but none stood out as a clear winner.
= Discussion =
I like the idea of redirecting users to .onion sites automatically when they type in the websites non-onion address. This way, users don't need to remember anything else, need to type in anything long, or really even know what onion sites are.
My suggestion is to follow the https design pattern, and create a similar indicator for .onion sites.
![onion-address-idea.png,600px](uploads/onion-address-idea.png,600px)
The proposed solution would be this: when a user types in a website (pad.riseup.net), they would automatically be redirected to the onion site. When this happens, there would be an onion icon next to the address bar (replacing the https lock icon if there is one, or just being there an https lock icon would be if redirection from an http website), similar to that of the https lock icon. The address in the address bar can turned a different color or indicated in some way that this is an alias for the onion site.
From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help). I speculate that they don't mind because they don't notice, and the reason why users freaked out at the redirect to onion sites is that they saw the website address visibly change in the address bar.
Also--
If we want to show users the address of the onion site, we can additionally have a feature to reveal the onion site when the user clicks in the address bar.
![onion-address-secondary-idea.png,600px](uploads/onion-address-secondary-idea.png,600px)
I don't know how I feel about this, since it may just be confusing, and just shock the user later. Users don't know that pad.riseup.net resolves to some numerical IP address, and that isn't displayed to users. So there could be an argument made for just indicating that the address is an alisas and not ever showing the .onion address, either. This will confuse way less of the general population.
= Considerations =
* how should the redirect behavior work?
* how can we implement this without tracking?
* should we allow users to turn off this redirecting behavior?
* should we hide the .onion address from the users more so than the proposal above?Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/21951Helping censored users bootstrap to Tor: Tor launcher improvements and automa...2020-06-16T01:01:15ZLinda LeeHelping censored users bootstrap to Tor: Tor launcher improvements and automation= Background =
[Research](https://petsymposium.org/2017/papers/issue3/paper2-2017-3-source.pdf) has shown that many censored users are not able to connect to Tor if Tor is censored in their country. The ones that are able to succeed us...= Background =
[Research](https://petsymposium.org/2017/papers/issue3/paper2-2017-3-source.pdf) has shown that many censored users are not able to connect to Tor if Tor is censored in their country. The ones that are able to succeed usually do after multiple attempts and minutes of their time.
To make this process faster and successful the first time, we need to be able to differentiate people connecting from different countries | people at risk and not at risk | people who are censored and not censored, tighten the window for error notifications and give advice, and generally make the settings easier to configure. One grand vision is to one day not involve users in toggling network settings, and to ask for consent and just give them one button that connects them to Tor safely and reliably.
= Objective =
To make it easier for users to connect to Tor, we're going to make some changes to Tor Launcher. We've broken this effort down into three stages:
1. design changes: we're going to make interface-only changes that will help the users.
1. naive automation: we're going to automate the connection process, by some sort of behavior. We haven't decided on what that behavior is yet, but there are multiple ways to do this. One way would be to try a bunch of relays/bridges in a specific order, and stop when one is reachable. Another way would be to try all the relays/bridges at the same time, and return one that works to the user.
1. smart automation: this is a "make it work" button that people can relatively safely click, and it will work for people in most environments with minimized risk. We haven't decided on what that behavior is yet either, but one way to do this is to meek-front the connection, work with bridgeDB and/or some way to identify where the user is from, and give them a relay/bridge that works the first time.Linda LeeLinda Leehttps://gitlab.torproject.org/legacy/trac/-/issues/21593drop tor2web from the website lists2020-06-13T17:24:27ZRoger Dingledinedrop tor2web from the website listsWe have a bunch of people who are concerned with tor2web, and think it needs to disappear. Maybe it does, maybe it doesn't, but I think it's fair to stop listing it as a Tor project on our website.
I think that's the official projects l...We have a bunch of people who are concerned with tor2web, and think it needs to disappear. Maybe it does, maybe it doesn't, but I think it's fair to stop listing it as a Tor project on our website.
I think that's the official projects list, and also the table on the volunteer page.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21321.onion HTTP is shown as non-secure in Tor Browser2020-06-15T23:46:51Zcypherpunks.onion HTTP is shown as non-secure in Tor Browserblog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
http version of .onion is safe. This must be the exception of that slash/ icon.blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
http version of .onion is safe. This must be the exception of that slash/ icon.https://gitlab.torproject.org/legacy/trac/-/issues/21222Main ticket for website redesign project2021-05-10T13:26:45ZIsabela FernandesMain ticket for website redesign project# Website redesign main ticket introduction
This is a huge project the UX team is leading and it has a lot of steps involved on it. Our goal is for this project to be the base of something that can scale while we continue to iterate on ...# Website redesign main ticket introduction
This is a huge project the UX team is leading and it has a lot of steps involved on it. Our goal is for this project to be the base of something that can scale while we continue to iterate on it.
# What problems are we trying to fix?
This project aims to fix many problems that goes beyond just a redesign thing, even though we are calling it 'website redesign'.
Yes, Tor Project website is not the best thing in the world and is a big problem that must be fixed. And this is a problem that we can't ignore anymore, is hurting many initiatives we have at Tor Project.
Our community is growing and this growth is part of the 'website problem'. A lot of information have been added to torproject.org over the years leading to what we have now. Is a good problem to have, but right now we must reorganize this information to better set ourselves to continue grow.
Here is a list of some problems easily recognizable with the current site:
* Not localized
* Too much information at the front page
* Still hard to find information
* Hard to add new information (ends up contributing to the mess) and we need to add more information because we are growing :) we have a lot to share
* inconsistency with the design
And we could go on but the point of this doc is not to have a full description of all the problems we have but just an introduction to set the stage for explaining what we are thinking for a solution and the steps of its implementation.
# How we solve it?
Our solution right now is to create new portals to better organize information and also at the same time keep torproject.org simple and easy for first comers to find their way around into what Tor is and how to get/use it.
So we will be building:
* torproject.org - with 'new user' as our main audience for this portal [of course with easy way to navigate to the other portals:
* dev.torproject.org - short explanation: "all things related to the development of free software projects of Tor Project"
* community.torproject.org - short explanation: "a umbrella of things that are power by our community, or a portal to 'help people help Tor'.
* support.torproject.org - user support website
Are we loosing press? FAQs? Donate page? The Blog? No :) the list above are the main entrance to all these things and more.
I invite you to read more about each of this portal and other work related to this initiative in the children tickets (and their children tickets) associated with this project. Is a big project and the information written here is a summary of the summary ;)
# Why now?
Right now we are with fund and a team to carry this work. And we need to do this to enable many other great work at Tor to have infrastructure to support their project. We believe that these portals will help a lot of groups inside of Tor Project to better provide information about their work and therefore receive help to do so.
= The short version of the process we will follow for each portal =
#### process for each site will be:
0. content architecture - map current content related to the portal and organize it
1. whiteboard draw organization of the content into pages
2. wireframe these pages
3. create design for these pages [these include design reviews till we are happy with what we have]
4. start organizing content for the pages (with the design already done we will be working with that)
5. update high definition mockups with real content
6. guerrilla user testing #1
7. start coding the pages
8. once content is finished we upload them on transifex for translation to start
9. Once coding is done we can start QA by language (as translations gets complete)
10.[we could do another user test here too before launch if we want - or we can run one after lunch and continue iteration]
# What we will use to build it?
Right now we are testing Lektor for the framework to use:
https://trac.torproject.org/projects/tor/ticket/24275
We are also working on a project that will help us build the themes for these portals but also anyone else who would like to follow our style guidelines for their site.
We are creating a fork of bootstrap and changing its css based on our guidelines, we plan to use it to build the front end of the portals. You can follow this project here (and it's children tickets):
[ need to add ticket ]
Some portals like 'support' need a search tool as well. For that we are looking at:
[ need to add a ticket ]
# Are we planing to test things?
Yes, not only our framework but everything! We hope to do as many research and test we can, it will all depend on our bandwidth and resources. Since we have been working on building this 'testing' and 'research' steps into our processes we already have some stuff in place that can help us carry those on. We hope to continue to add more resources in this front to be able to do even more of those in the future!
This project is actually the first year of a 3 years project where we hope to build this user feedback / testing process and have it happening in large scale for all the projects we are working on.
# What about translation?
We will localize first:
* torproject.org
* support.torproject.org
The languages we will support are our tier1 languages :
https://storm.torproject.org/shared/o7Rh2S9bsMNN7Eh7C9cKaqxR371pR1AmpRxbu--nC34
1. English - EN
1. Farsi - FA
1. Spanish - ES
1. Russian - RU
1. Simplified Chinese - zh-CN
1. Portuguese - PT-BR
1. French - FR
1. German - DE
1. Korean - KO
1. Turkish - TR
1. Italian - IT
1. Arabic - AR
Translation will be done using Transifex community, thousands of people who have already been translating other Tor things.
We will add a step for Localization Review of the translated sites with a native speaker of each language. So we can have a review in context since as many other crowdsourcing translation tools, translation within context is something they miss. But they do have other features, such as translation memory and vocabulary features that helps a lot on making sure of the translation quality across so many pages and product UIs.
So we will stick with the good practices of using a good tool like Transifex to do the translation and incorporate a review in context step with native speakers. Hopefully we will have volunteers to help us out with all those tier 1 languages.
# What have we done
''__***this part is not done yet***
__''The story of Tor Project website is long! But to cut it short we will talk from 2015 - now (EOY 2017)
This work will incorporate work from [past efforts](https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign). We did some work on the [support page](https://trac.torproject.org/projects/tor/wiki/doc/UX/SupportPage) before this site-wide effort.website redesignIsabela FernandesIsabela Fernandeshttps://gitlab.torproject.org/legacy/trac/-/issues/21183Basic Usability Issues2020-06-15T23:46:01ZTracBasic Usability IssuesHi:
I'm a longtime UX'er, and new to using Tor. Some very basic heuristics I felt compelled to respond to, in a PDF—and was advised by a FOSS person, to submit in a ticket, here.
Namely:
- The "Tor Button" is illegible (recommended re...Hi:
I'm a longtime UX'er, and new to using Tor. Some very basic heuristics I felt compelled to respond to, in a PDF—and was advised by a FOSS person, to submit in a ticket, here.
Namely:
- The "Tor Button" is illegible (recommended replacement included)
- The "NoScripts" icon is illegible (recommended replacement included)
- Most of the functionality behind the TorButton should be in a preferences pane, not a toolbar button
- The three pieces of functionality appropriate for toolbar buttons, should each have their own buttons. Replacement icons and interaction pane recommendations, included.
Document here, if I'm not able to upload it myself:
https://drive.google.com/open?id=0BzRaXGZ006aoWHJLd0hBT3IyRUE
**Trac**:
**Username**: ninavizz