Web Team issueshttps://gitlab.torproject.org/tpo/web/team/-/issues2024-02-08T18:44:14Zhttps://gitlab.torproject.org/tpo/web/team/-/issues/48make a post-mortem forllowing the YEC 2023 launch2024-02-08T18:44:14Zanarcatmake a post-mortem forllowing the YEC 2023 launchjust a ticket to keep track of issues we find during the YEC 2023 launch today
- [ ] https://gitlab.torproject.org/tpo/web/blog/-/merge_requests/228 was merged without review, and prior to when @lavamind and @mattlav were around to hand...just a ticket to keep track of issues we find during the YEC 2023 launch today
- [ ] https://gitlab.torproject.org/tpo/web/blog/-/merge_requests/228 was merged without review, and prior to when @lavamind and @mattlav were around to handle the actual launch
- [ ] tor browser start announcing the launch before the time as well
- [ ] TPA (@anarcat) postponed the launch from "midnight UTC" to "morning America/Eastern" without proper coordination
- [ ] translation strings were sent to @emmapeel too late
- [ ] the donate website is under documented, a total mess, and hard to test
- [ ] specifically, it was believed it was not possible to test the donation workflow in staging
This is not to lay blame on anyone, nor to divert us from the YEC. Those are issues we can look at much later.
ideas for future improvements:
- organize the timeline on GitLab milestones and issues (or at least Nextcloud) instead of a private Google Docs, and keep tickets up to date with progress
- have a point person responsible for technical coordination that's available for the week before launch, during launch, and after launch
- ensure testing is performed long before launch
- ensure translations are ready before launch
- ensure donate.tpo is up to date before sending announcements
- document deployment workflows properly
- communicate clearly, to all stakeholders, when a blocker occurs
/cc @lavamind @mattlav @gabaYear End Campaign 2023anarcatanarcathttps://gitlab.torproject.org/tpo/web/team/-/issues/21Working around the POT templates being inserted into lektor contents2024-01-18T14:39:00ZKezWorking around the POT templates being inserted into lektor contentsI've spent a few hours digging into lektor-i18n-plugin and trying to figure out what causes lego#37. I've discovered that running `lektor b` with python 3.9+ creates different .po/.pot files than running with python 3.8.x. The main diffe...I've spent a few hours digging into lektor-i18n-plugin and trying to figure out what causes lego#37. I've discovered that running `lektor b` with python 3.9+ creates different .po/.pot files than running with python 3.8.x. The main difference is that the buggy translation files translate the empty string `""` as the PO text.
I'm writing this up in detail in case someone else wants to pick up where I've left off, and also to document where exactly the bug is occuring.
The lektor-i18n-plugin code goes through each translation block, and if translating linewise (the default, also what we use), splits each translation block on `\n`, and then translates:
```py
def __trans_linewise(self, content, translator):
"""Translate the chunk linewise."""
lines = []
for line in content.split('\n'):
line_stripped = line.strip()
trans_stripline = trans(translator, line_stripped) # translate the stripped version
# and re-inject the stripped translation into original line (not stripped)
lines.append(line.replace(line_stripped,
trans_stripline, 1))
return '\n'.join(lines)
```
This means that translation blocks that end in a newline end up split into a list like this:
```py
content = 'lorem ipsum\ndolor sit amet\n'
split_lines = ['lorem ipsum' 'dolor sit amet', '']
```
Notice the empty string at the end of the list; this will get translated to the PO text we've been seeing. A simple workaround is to just not translate empty strings:
```py
...
for line in content.split('\n'):
line_stripped = line.strip()
if line_stripped == '':
trans_stripline = ''
else:
trans_stripline = trans(translator, line_stripped)
...
```
I'm not entirely happy with this since the bug is still *present*, we're just avoiding the consequences of it by ignoring empty strings. It feels fragile, but as long as we don't do anything with the buggy translation files that the plugin generates, we should be fine.
I'm hesitant on sending a patch for this upstream because it's not an actual fix. The alternative is maintaining a fork of the plugin in lego with our patch applied.https://gitlab.torproject.org/tpo/web/team/-/issues/44Archive and redirect gettor.torproject.org landing page to support portal2024-01-11T13:54:11ZGusArchive and redirect gettor.torproject.org landing page to support portalAlthough GetTor service is very important and useful for users where torproject.org website is blocked, I don't get what's the point of having GetTor landing page since all the instructions are available on Support portal and on Tor Brow...Although GetTor service is very important and useful for users where torproject.org website is blocked, I don't get what's the point of having GetTor landing page since all the instructions are available on Support portal and on Tor Browser Manual, which is bundled in TB.
So, here is my proposal to archive and redirect gettor.torproject.org:
- Improve gettor entry on https://support.torproject.org/censorship
- Archive the repository: https://gitlab.torproject.org/tpo/web/gettor-web
- Redirect gettor.torproject.org to support.torproject.org/censorship
- Remove gettor-web from weblateSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetemmapeelemmapeelhttps://gitlab.torproject.org/tpo/web/team/-/issues/49test- and staging- sites are indexed by google2024-01-09T19:47:34ZKeztest- and staging- sites are indexed by googlein donate#13 mattlav discovered that google is indexing our testing and staging sites, and sometimes a search returns results for one of those sites instead of our actual production sites.
we should modify the robots.txt files for these...in donate#13 mattlav discovered that google is indexing our testing and staging sites, and sometimes a search returns results for one of those sites instead of our actual production sites.
we should modify the robots.txt files for these sites to block indexing across the entire sitehttps://gitlab.torproject.org/tpo/web/team/-/issues/39merge the two web wikis2023-07-04T19:16:14Zanarcatmerge the two web wikisi hadn't realized this, but we have two web wikis. that is bad. let's not do that and merge them both... here?
https://gitlab.torproject.org/tpo/web/wiki/-/wikis/home
https://gitlab.torproject.org/tpo/web/team/-/wikis/home
/cc @emmapeeli hadn't realized this, but we have two web wikis. that is bad. let's not do that and merge them both... here?
https://gitlab.torproject.org/tpo/web/wiki/-/wikis/home
https://gitlab.torproject.org/tpo/web/team/-/wikis/home
/cc @emmapeelanarcatanarcathttps://gitlab.torproject.org/tpo/web/team/-/issues/28TPA-RFC-16: Replacing lektor-i18n-plugin [Discussion]2023-05-15T20:46:41ZKezTPA-RFC-16: Replacing lektor-i18n-plugin [Discussion]I'm creating this ticket as the discussion for [TPA-RFC-16](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-16-replacing-lektor-i18n-plugin). Please add any feedback, ideas, criticism, and suggestions for the RFC in thi...I'm creating this ticket as the discussion for [TPA-RFC-16](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-16-replacing-lektor-i18n-plugin). Please add any feedback, ideas, criticism, and suggestions for the RFC in this ticket.https://gitlab.torproject.org/tpo/web/team/-/issues/43compress more ressources2023-02-13T21:03:48Ztrinity-1686acompress more ressourcesWhile looking at tpo/tpa/team#40900, I found that `SourceSansPro-*.ttf` fonts are consuming a substantial amount of bandwidth. Over the 22nd, they collectively account for around 258GB of bandwidth usage for www.tpo (a bit more including...While looking at tpo/tpa/team#40900, I found that `SourceSansPro-*.ttf` fonts are consuming a substantial amount of bandwidth. Over the 22nd, they collectively account for around 258GB of bandwidth usage for www.tpo (a bit more including other domains, and for context it was a very busy day).
They are served raw, but could be served compressed. That would have been around 114GB if everything was sent gzipped, 89GB if it was compressed with brotli.
Compressing would then reduce the load on webservers, but also make the website load faster for slower clients (290kB ~= 2.2s at 1Mbps), so I think it would be a good thing to do on all accounthttps://gitlab.torproject.org/tpo/web/team/-/issues/19Update wiki docs about our website development workflow in accordance with th...2023-02-13T18:41:01Zchampionquizzerchampionquizzer@torproject.orgUpdate wiki docs about our website development workflow in accordance with the GitLab CI migrationAs discussed in the Community Team meeting today, we need to update the wiki pages, for instance:
https://gitlab.torproject.org/tpo/web/wiki/-/wikis/Compiling-a-local-version-of-the-website
https://gitlab.torproject.org/tpo/web/wiki/-...As discussed in the Community Team meeting today, we need to update the wiki pages, for instance:
https://gitlab.torproject.org/tpo/web/wiki/-/wikis/Compiling-a-local-version-of-the-website
https://gitlab.torproject.org/tpo/web/wiki/-/wikis/How-to-enable-a-new-locale
We also need to review (and update) the docs at other places:
https://gitlab.torproject.org/tpo/web/tpo/-/blob/main/CONTRIBUTING.md
https://gitlab.torproject.org/tpo/web/tpo/-/blob/main/README.md
https://gitlab.torproject.org/tpo/web/community/-/blob/main/README.mdhttps://gitlab.torproject.org/tpo/web/team/-/issues/47enable "pipelines must succeed" setting on all web repos2023-02-02T19:49:51ZKezenable "pipelines must succeed" setting on all web reposlavamind found a "pipelines must succeed" setting under `gitlab.torproject.org/tpo/web/<repo>/-/settings/merge_requests` under the section "Merge checks", and suggested we apply it to all the web repos.
- [x] blog
- [x] community
- [x] ...lavamind found a "pipelines must succeed" setting under `gitlab.torproject.org/tpo/web/<repo>/-/settings/merge_requests` under the section "Merge checks", and suggested we apply it to all the web repos.
- [x] blog
- [x] community
- [x] dev
- [x] donate-static
- [x] gettor-web
- [x] manual
- [x] newsletter
- [x] research
- [x] social-bank
- [x] styleguide
- [x] support
- [x] tpohttps://gitlab.torproject.org/tpo/web/team/-/issues/46Tor browser URLs with (ga-IE) locale code are not always redirected2022-12-06T14:54:38ZhenryTor browser URLs with (ga-IE) locale code are not always redirectedWithin tor browser, we have a few links that insert the application locale into the URL
- `https://support.torproject.org/<locale>/`
- `https://tb-manual.torproject.org/<locale>/`
- `https://community.torproject.org/<locale>/`
However,...Within tor browser, we have a few links that insert the application locale into the URL
- `https://support.torproject.org/<locale>/`
- `https://tb-manual.torproject.org/<locale>/`
- `https://community.torproject.org/<locale>/`
However, these do not redirect when the locale code is "ga-IE", even though that is one of the application locales we supply. "ga" still works though.
I haven't tested all the locales, but most of them seem to work. Maybe this is the only exception, but it would be nice if the rules could be checked against all the locales we ship with https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/3afab9a8af2b41f6b3cb4714d94ecab690911edb/rbm.conf#L98emmapeelemmapeelhttps://gitlab.torproject.org/tpo/web/team/-/issues/32The future of media.tpo2022-10-26T23:23:24ZKezThe future of media.tpoIn #30 @emmapeel brought up the fact we have a media.tpo service that is undocumented and seemingly unmaintained, and unused. Until I updated the README today, the last update was in Dec. 2018. We aren't using the service right now, so i...In #30 @emmapeel brought up the fact we have a media.tpo service that is undocumented and seemingly unmaintained, and unused. Until I updated the README today, the last update was in Dec. 2018. We aren't using the service right now, so it there are several options for what we should do with it:
- Keep the service as it is, adding documentation, and possibly restoring rsync
- Start using the service more actively, with documentation and possibly restoring rsync
- Decommission the service entirely
@lavamind, @anarcat, @gaba, and I discussed this a bit in the monthly TPA sync today. We decided we shouldn't make any moves on this without talking to the comms team about it. Since lavamind and I are going to be meeting with the comms team for the S9 meeting on Thursday, we've decided to bring it up then.https://gitlab.torproject.org/tpo/web/team/-/issues/37Extend merge permissions for web projects2022-09-08T14:00:45ZJérôme Charaouilavamind@torproject.orgExtend merge permissions for web projectsCurrently, when members of other teams such as comms or applications want to publish a blog post or a new software release, they need someone from the web team (who have `Maintainer` permissions in tpo/web projects) to accept (merge) the...Currently, when members of other teams such as comms or applications want to publish a blog post or a new software release, they need someone from the web team (who have `Maintainer` permissions in tpo/web projects) to accept (merge) their Merge Request and also to push the latest CI build to production.
This process puts extra load on the web team, as their intervention is required on all web changes, even though some changes are quite trivial and should not require any manual review of MRs. Furthermore, it also puts extra load on the other teams as they need to follow-up at different moments of the publishing process to ensure someone from the web team steps in, otherwise the process is blocked.
I would like to propose to grant the members of projects under [tpo/web](/tpo/web) with **Developper** permission, the power to accept Merge requests. This change would also allow them to trigger manual deployments to production. This way, we will avoid blocking on the web team for small, common and regular website updates. Of course, the web team will remain available to review all the other, more substantial or unusual website updates.
To make this change, under each project's `Settings -> Repository -> Protected branches`, for the `main` branch, the **Allowed to merge** option would change from `Maintainers` to `Maintainers + Developpers`. **Allowed to push** would remain set to `Maintainers` (so Developpers would still always need to submit MRs).
In order to ensure no one is granted permissions they should not have, we should, at the same time, verify that only core contributors of the Tor Project are assigned Developper permissions on these projects.
* [x] [tpo/web/blog](/tpo/web/blog)
* [x] [tpo/web/tpo](/tpo/web/tpo)
* [ ] ~~[tpo/web/donate-static](/tpo/web/donate-static)~~
* [ ] ~~[tpo/web/gettor-web](/tpo/web/gettor-web)~~
* [ ] ~~[tpo/web/manual](/tpo/web/manual)~~
* [ ] ~~[tpo/web/newsletter](/tpo/web/newsletter)~~
* [ ] ~~[tpo/web/research](/tpo/web/research)~~
* [ ] ~~[tpo/web/styleguide](/tpo/web/styleguide)~~
* [ ] ~~[tpo/web/support](/tpo/web/support)~~
/cc @gaba @gus @emmapeel @anarcat @kezGabagaba@torproject.orgGabagaba@torproject.org2022-05-20https://gitlab.torproject.org/tpo/web/team/-/issues/16Lektor projects may not want all packages in lego2022-08-02T21:48:22ZJérôme Charaouilavamind@torproject.orgLektor projects may not want all packages in legoThe way most of the Lektor website projects are built, with `packages` symlinked to `lego/packages` is not ideal. For example, the `i18n` plugin is present on projects which do not need it, and when the plugin [started to misbehave](tpo/...The way most of the Lektor website projects are built, with `packages` symlinked to `lego/packages` is not ideal. For example, the `i18n` plugin is present on projects which do not need it, and when the plugin [started to misbehave](tpo/tpa/team#40501), it affected all projects and not only the ones that need `i18n`.
If projects instead symlinked packages selectively from those in `lego/packages` we would avoid this, and gain the ability for projects to use their own plugins without affecting the other sites (eg. `index-pages` for the blog project).
Furthermore it would probably be wise to revisit just why exactly some packages are in there, such as `environs`.https://gitlab.torproject.org/tpo/web/team/-/issues/40Links to "Commented on issue" on GitLab user's activity use https on the onio...2022-06-14T14:13:53ZPier Angelo VendrameLinks to "Commented on issue" on GitLab user's activity use https on the onion serviceIf you go to GitLab user's activity from the onion service, the "Commented on issue #..." entries have a HTTPS URL instead of a HTTP one.
![Screenshot_from_2022-06-14_15-05-20](/uploads/749e2cb69363351c25bc909d17dd3f09/Screenshot_from_2...If you go to GitLab user's activity from the onion service, the "Commented on issue #..." entries have a HTTPS URL instead of a HTTP one.
![Screenshot_from_2022-06-14_15-05-20](/uploads/749e2cb69363351c25bc909d17dd3f09/Screenshot_from_2022-06-14_15-05-20.png)
All the other links seem to work.https://gitlab.torproject.org/tpo/web/team/-/issues/36Rework GitLab-IRC bot alerts for #tor-www2022-06-08T17:37:43ZJérôme Charaouilavamind@torproject.orgRework GitLab-IRC bot alerts for #tor-wwwThere are several events in GitLab for which alerts in #tor-www would be very useful:
* Blocking on manual `deploy-prod` jobs
* New merge requests
* Failed pipelines
Maybe there's more. At the moment, using the KGB IRC bot, it's not p...There are several events in GitLab for which alerts in #tor-www would be very useful:
* Blocking on manual `deploy-prod` jobs
* New merge requests
* Failed pipelines
Maybe there's more. At the moment, using the KGB IRC bot, it's not possible to filter messages at that level of precision. For example, we can only control whether all "Pipeline events" are shown or not.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/team/-/issues/38Broken link on archive.torproject.org2022-05-12T16:23:06ZsreadyBroken link on archive.torproject.orgIn README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?In README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?anarcatanarcathttps://gitlab.torproject.org/tpo/web/team/-/issues/29Websites should provide Khmer font2022-05-06T01:39:43ZemmapeelWebsites should provide Khmer fontIt seems our new upcoming locale Khmer lektor locale is not well supported in all operating systems utf-8. When opening https://review.torproject.net/tpo/web/manual/l10n/km/:
In Firefox the website looks good:
![firefox](/uploads/9181f2...It seems our new upcoming locale Khmer lektor locale is not well supported in all operating systems utf-8. When opening https://review.torproject.net/tpo/web/manual/l10n/km/:
In Firefox the website looks good:
![firefox](/uploads/9181f2aa33ee7363cc96729b38b00aac/firefox.png)
But in KaliOS you see this until you install the Khmer Unicode package:
![kali-Screen_Shot_2022-02-23_at_3.37.24_PM](/uploads/18319c3af023a0900fdc0aefeb9a199e/kali-Screen_Shot_2022-02-23_at_3.37.24_PM.jpeg)
And in Tor Browser in Tails you see some weird crosses under the letters:
![titles](/uploads/6e172a048c065264e714384db608bc38/titles.png)
We should provide a font for the readers to be able to read the website.
The Khmer translators said:
```
we have many unicode khmer fonts but not all work well with dif. platforms
```
They propose the font Hanuman:
https://fonts.google.com/specimen/Hanuman?subset=khmer
Because if there are problems with this font, they can talk to the developerhttps://gitlab.torproject.org/tpo/web/team/-/issues/20Replace the github 'edit this page' links with gitlab links2022-05-06T01:39:43ZemmapeelReplace the github 'edit this page' links with gitlab linksNow it is easier to open accounts on this gitlab instance.
Also, since our website branches got protected, we need to push a merge request to the gitlab repo to be able to merge changes.
So it would be easier to review and merge update...Now it is easier to open accounts on this gitlab instance.
Also, since our website branches got protected, we need to push a merge request to the gitlab repo to be able to merge changes.
So it would be easier to review and merge updates if users submit their merge requests on gitlab.
One way of improving this is to change the 'Edit this page' link at the bottom of some of the websites, that is currently pointing to our github mirror, and make it point to the repos in this gitlab instance.
Changes should be done in:
- [ ] Support.tpo
- [ ] TB-manual.tpo
- [ ] Community.tpohttps://gitlab.torproject.org/tpo/web/team/-/issues/17Link from the Swag page to the t-shirt inventory wiki page2022-03-30T23:45:46ZKatLink from the Swag page to the t-shirt inventory wiki pageOn https://community.torproject.org/relay/community-resources/swag/, the text "a variety of colors, shapes, and sizes" should link to the t-shirt inventory wiki page: https://gitlab.torproject.org/tpo/community/team/-/wikis/tshirts.On https://community.torproject.org/relay/community-resources/swag/, the text "a variety of colors, shapes, and sizes" should link to the t-shirt inventory wiki page: https://gitlab.torproject.org/tpo/community/team/-/wikis/tshirts.https://gitlab.torproject.org/tpo/web/team/-/issues/34Deploy staging sites for all web projects2022-03-29T20:10:35ZJérôme Charaouilavamind@torproject.orgDeploy staging sites for all web projectsAs agreed at the March 17th S9 meeting, the web team agreed to implement the same review/staging/production workflow across our different projects. This issue will track this progress.
Subdomains of `staging.torproject.net` will be crea...As agreed at the March 17th S9 meeting, the web team agreed to implement the same review/staging/production workflow across our different projects. This issue will track this progress.
Subdomains of `staging.torproject.net` will be created for this purpose. They will have a new static component in our web mirror system and an associated ssh private key will be added to each project's CI variables..
* [x] blog.staging.torproject.net
* [x] community.staging.torproject.net
* [x] ~~dev.staging.torproject.net~~ (in development, not on static mirrors yet)
* [x] donate.staging.torproject.net
* [x] gettor.staging.torproject.net
* [x] tb-manual.staging.torproject.net
* [x] newsletter.staging.torproject.net
* [x] research.staging.torproject.net
* [x] status.staging.torproject.net
* [x] styleguide.staging.torproject.net
* [x] support.staging.torproject.net
* [x] www.staging.torproject.net
Cleanup (vhost, docroots and LE configs):
* [x] blog-staging.torproject.org
* [x] support-staging.torproject.org
* [x] www-staging.torproject.orgJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org