Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: Correct “webapp” to “web app”. 

Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
Anders Kaseorg 2021-05-13 15:16:30 -07:00 committed by Tim Abbott
parent e3c570401e
commit e015f3ed7d
51 changed files with 104 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/contributing/chat-zulip-org.md
View File

@ -93,7 +93,7 @@ descriptions for all of them. Relevant to almost everyone are these:
folks post with their name as the topic. Everyone is welcome to
participate!
* [#development help](https://chat.zulip.org/#narrow/stream/49-development-help)
is for asking for help with any Zulip server/webapp development work
is for asking for help with any Zulip server/web app development work
(use the app streams for help working on one of the apps).
* [#code review](https://chat.zulip.org/#narrow/stream/91-code-review)
is for getting feedback on your work. We encourage all developers

14
docs/contributing/gsoc-ideas.md
View File

@ -258,10 +258,10 @@ the areas mentioned above are not your main strength.
As a data point, in Summer 2017, we had 4 students working on the
React Native mobile app (1 focused primarily on visual design), 1 on
the Electron desktop app, 2 on bots/integrations, 1 on webapp visual
the Electron desktop app, 2 on bots/integrations, 1 on web app visual
design, 2 on our development tooling and automated testing
infrastructure, and the remaining 4 on various other parts of the
backend and core webapp.
backend and core web app.
### Full stack and web frontend focused projects
@ -306,7 +306,7 @@ CSS](https://github.com/zulip/zulip/).
Expert: Eeshan Garg.
- Optimize performance and scalability, either for the web frontend or
the server. Zulip is already one of the faster webapps out there,
the server. Zulip is already one of the faster web apps out there,
but there are a bunch of ideas for how to make it substantially
faster. This is likely a particularly challenging project to do
well, since there are a lot of subtle interactions to understand.
@ -322,8 +322,8 @@ CSS](https://github.com/zulip/zulip/).
[prod-label]: https://github.com/zulip/zulip/issues?q=is%3Aopen+is%3Aissue+label%3A%22area%3A+production%22
- Extract JavaScript logic modules from the Zulip webapp that we'd
like to be able to share with the Zulip webapp. This work can have
- Extract JavaScript logic modules from the Zulip web app that we'd
like to be able to share with the Zulip web app. This work can have
big benefits it terms of avoiding code duplication for complex
logic. We have prototyped for a few modules by migrating them to
`static/shared/`; this project will involve closely collaborating
@ -511,7 +511,7 @@ Zulip React Native mobile app.
problems that nobody has found yet; in the short term, it needs
polish, bug finding/squashing, and debugging. So browse the open
issues, play with the app, and get involved! Goals include parity
with the webapp (in terms of what you can do), parity with Slack (in
with the web app (in terms of what you can do), parity with Slack (in
terms of the visuals), world-class scrolling and narrowing
performance, and a great codebase.
@ -556,7 +556,7 @@ Experts: Aman Agrawal, Neil Pilgrim.
- Work on Zulip Terminal, the official terminal client for Zulip.
zulip-terminal is already a basic usable client, but it needs a lot
of work to approach the webapp's quality level. We would be happy
of work to approach the web app's quality level. We would be happy
to accept multiple strong students to work on this project. Our
goal for this summer is to improve its quality enough that we can
upgrade it from an alpha to an advertised feature. **Skills

4
docs/development/using.md
View File

@ -5,7 +5,7 @@ This page describes the basic edit/refresh workflows for working with
the Zulip development environment. Generally, the development
environment will automatically update as soon as you save changes
using your editor. Details for work on the [server](#server),
[webapp](#web), and [mobile apps](#mobile) are below.
[web app](#web), and [mobile apps](#mobile) are below.
If you're working on authentication methods or need to use the [Zulip
REST API][rest-api], which requires an API key, see [authentication in
@ -80,7 +80,7 @@ the development environment][authentication-dev-server].
reloaded automatically.
* For Jinja2 backend templates (`templates/*`), you'll need to reload
the browser window to see your changes.
* Any JavaScript exceptions encountered while using the webapp in a
* Any JavaScript exceptions encountered while using the web app in a
development environment will be displayed as a large notice, so you
don't need to watch the JavaScript console for exceptions.
* Both Chrome and Firefox have great debuggers, inspectors, and

4
docs/overview/architecture-overview.md
View File

@ -6,7 +6,7 @@ Key codebases
The main Zulip codebase is at <https://github.com/zulip/zulip>. It
contains the Zulip backend (written in Python 3.x and Django), the
webapp (written in JavaScript and TypeScript) and our library of
web app (written in JavaScript and TypeScript) and our library of
incoming webhook [integrations](https://zulip.com/integrations)
with other services and applications (see [the directory structure
guide](../overview/directory-structure.md)).
@ -105,7 +105,7 @@ the code is in `zerver/tornado`.
Zulip's HTML is primarily implemented using two types of HTML
templates: backend templates (powered by the [Jinja2][] template
engine used for logged-out ("portico") pages and the webapp's base
engine used for logged-out ("portico") pages and the web app's base
content) and frontend templates (powered by [Handlebars][]) used for
live-rendering HTML from JavaScript for things like the main message
feed.

16
docs/overview/changelog.md
View File

@ -90,7 +90,7 @@ log][commit-log] for an up-to-date list of raw changes.
inline documentation in your
`/etc/zulip/settings.py`][update-settings-docs]. Notably, we rewrote the
template to be better organized and more readable in this release.
- The webapp will now display a warning in the UI if the Zulip server
- The web app will now display a warning in the UI if the Zulip server
has not been upgraded in more than 18 months.
template to be better organized and more readable.
- The next time users log in to Zulip with their password after
@ -212,7 +212,7 @@ log][commit-log] for an up-to-date list of raw changes.
- Upgraded our ancient forked version of bootstrap, on a path towards
removing the last forked dependencies from the codebase.
- Upgraded Django to 3.1 (as well as essentially every other dependency).
- Updated webapp codebase to use many modern ES6 patterns.
- Updated web app codebase to use many modern ES6 patterns.
- Upgraded Zulip's core font to Source Sans 3, which supports more languages.
- Relabeled :smile: and :stuck_out_tongue: emoji to use better codepoints.
- Reduced the size of Zulip's main JavaScript bundle by removing `moment.js`.
@ -724,10 +724,10 @@ lose the setting and need to re-enable it.
verify whether your configuration is working correctly.
- The Zulip web and desktop apps have been converted to directly count
all unread messages, replacing an old system that just counted the
(recent) messages fully fetched by the webapp. This one-time
(recent) messages fully fetched by the web app. This one-time
transition may cause some users to notice old messages that were
sent months or years ago "just became unread". What actually
happened is the user never read these messages, and the Zulip webapp
happened is the user never read these messages, and the Zulip web app
was not displaying that. Generally, the fix is for users to simply
mark those messages as read as usual.
- Previous versions of Zulip's installer would generate the secrets
@ -753,7 +753,7 @@ lose the setting and need to re-enable it.
#### Full feature changelog
- Added sortable columns to all tables in settings pages.
- Added webapp support for self-service public data exports.
- Added web app support for self-service public data exports.
- Added 'e' keyboard shortcut for editing currently selected message.
- Added support for unstarring all starred messages.
- Added support for using `|` as an OR operator in sidebar search features.
@ -771,7 +771,7 @@ lose the setting and need to re-enable it.
convenient to link to profiles on GitHub, Twitter, and other tools.
- Added support for choosing which email address to use in GitHub auth.
- Added a new setting to control whether inactive streams are demoted.
- Added webapp support for new desktop app features: inline reply
- Added web app support for new desktop app features: inline reply
from notifications, and detecting user presence from OS APIs.
- Added Markdown support for headings, implemented using `# heading`,
and removed several other unnecessary differences from CommonMark.
@ -866,7 +866,7 @@ lose the setting and need to re-enable it.
- Fixed guest users seeing UI widgets they can't use.
- Fixed several issues with click handlers incorrectly closing compose.
- Fixed buggy behavior of /me messages not ending with a paragraph.
- Fixed several major UI issues with the mobile webapp.
- Fixed several major UI issues with the mobile web app.
- Fixed HTML styling when copy-pasting content out of Zulip's night theme.
- Fixed obscure traceback with Virtualenv 16.0.0 unexpectedly installed.
- Added a new visual tool for testing webhook integrations.
@ -1166,7 +1166,7 @@ Zulip installations; it has minimal changes for existing servers.
- Fixed several bugs with progress bars when uploading files.
- Fixed several bugs in `manage.py register_server`.
- Fixed several minor real-time sync issues with stream settings.
- Fixed some tricky corner cases with the webapp's caching model and
- Fixed some tricky corner cases with the web app's caching model and
narrowing to the first unread message.
- Fixed confusing intermediate states of group PMs online indicators.
- Fixed several subtle unread count corner case bugs.

12
docs/overview/release-lifecycle.md
View File

@ -18,12 +18,12 @@ security support policies. In short:
highly recommend subscribing so that you are notified about new
security releases.
* Zulip Cloud runs the branch that will become the next major
server/webapp release, so it is always "newer" than the latest
server/web app release, so it is always "newer" than the latest
stable release.
## Server and webapp
## Server and web app
The Zulip server and webapp are developed together in the [Zulip
The Zulip server and web app are developed together in the [Zulip
server repository][zulip-server].
### Stable releases
@ -44,7 +44,7 @@ server repository][zulip-server].
upgrading to the latest maintenance release in that series, so that
you use the latest version of the upgrade code.
Starting with Zulip 4.0, the Zulip webapp displays the current server
Starting with Zulip 4.0, the Zulip web app displays the current server
version in the gear menu. With older releases, the server version is
available [via the API](https://zulip.com/api/get-server-settings).
@ -126,7 +126,7 @@ See also our [security model][security-model] documentation.
### Upgrade nag
Starting with Zulip 4.0, the Zulip webapp will display a banner
Starting with Zulip 4.0, the Zulip web app will display a banner
warning users of a server running a Zulip release that is more than 18
months old. We do this for a few reasons:
@ -210,7 +210,7 @@ of our [upgrade nag](#upgrade-nag).
upgrade all users after a new security release.
New desktop app releases rarely contain new features, because the
desktop app tab inherits its features from the Zulip server/webapp.
desktop app tab inherits its features from the Zulip server/web app.
However, it is important to upgrade because they often contain
important security or OS compatibility fixes from the upstream
Chromium project.

2
docs/production/authentication-methods.md
View File

@ -456,7 +456,7 @@ IdP.
### IdP-initiated SSO
The above configuration is sufficient for Service Provider initialized
SSO, i.e. you can visit the Zulip webapp and click "Sign in with
SSO, i.e. you can visit the Zulip web app and click "Sign in with
{IdP}" and it'll correctly start the authentication flow. If you are
not hosting multiple organizations, with Zulip 3.0+, the above
configuration is also sufficient for Identity Provider initiated SSO,

2
docs/subsystems/caching.md
View File

@ -252,7 +252,7 @@ apps; details like which users exist, with metadata like names and
avatars, similar details for streams, recent message history, etc.
This data is fetched in the `/register` endpoint (or `page_params`
for the webapp), and kept correct over time. The key to keeping these
for the web app), and kept correct over time. The key to keeping these
state up to date is Zulip's
[real-time events system](../subsystems/events-system.md), which
allows the server to notify clients whenever state that might be

2
docs/subsystems/dependencies.md
View File

@ -81,7 +81,7 @@ no longer had time for them.
One case where we apply added scrutiny to third-party dependencies is
JS libraries. They are a particularly important concern because we
want to keep the Zulip webapp's JS bundle small, so that Zulip
want to keep the Zulip web app's JS bundle small, so that Zulip
continues to load quickly on systems with low network bandwidth.
We'll look at large JS libraries with much greater scrutiny for
whether their functionality justifies their size than Python

2
docs/subsystems/emoji.md
View File

@ -43,7 +43,7 @@ able to support deprecating old realm emoji in a sensible way.
We use the [iamcal emoji data package][iamcal] to provide sprite
sheets and individual images for our emoji, as well as a data set of
emoji categories, code points, etc. The sprite sheets are used
by the Zulip webapp to display emoji in messages, emoji reactions,
by the Zulip web app to display emoji in messages, emoji reactions,
etc. However, we can't use the sprite sheets in some contexts, such
as missed-message and digest emails, that need to have self-contained
assets. For those, we use individual emoji files under

2
docs/subsystems/events-system.md
View File

@ -386,7 +386,7 @@ coverage data.
#### page_params
In the Zulip webapp, the data returned by the `register` API is
In the Zulip web app, the data returned by the `register` API is
available via the `page_params` parameter.
### Messages

2
docs/subsystems/hashchange-system.md
View File

@ -39,7 +39,7 @@ different flows:
another part of the overlay, which should update the hash but not
re-trigger loading the overlay (which would result in a confusing
animation experience).
* The user is in a part of the webapp, and reloads their browser window.
* The user is in a part of the web app, and reloads their browser window.
Ideally the reloaded browser window should return them to their
original state.
* A server-initiated browser reload (done after a new version is

2
docs/subsystems/html-css.md
View File

@ -76,7 +76,7 @@ context is defined and where it can be found.
### Backend templates
For text generated in the backend, including logged-out ("portico")
pages and the webapp's base content, we use the [Jinja2][] template
pages and the web app's base content, we use the [Jinja2][] template
engine (files in `templates/zerver`).
The syntax for using conditionals and other common structures can be

20
docs/subsystems/performance.md
View File

@ -9,10 +9,10 @@ First, a few notes on philosophy.
* We consider it an important technical goal for Zulip to be fast,
because that's an important part of user experience for a real-time
collaboration tool like Zulip. Many UI features in the Zulip webapp
collaboration tool like Zulip. Many UI features in the Zulip web app
are designed to load instantly, because all the data required for
them is present in the initial HTTP response, and both the Zulip
API and webapp are architected around that strategy.
API and web app are architected around that strategy.
* The Zulip database model and server implementation are carefully
designed to ensure that every common operation is efficient, with
automated tests designed to prevent the accidental introductions of
@ -177,9 +177,9 @@ The request to generate the `page_params` portion of `GET /`
/api/v1/register](https://zulip.com/api/register-queue) used by
mobile/terminal apps) is one of Zulip's most complex and expensive.
Zulip is somewhat unusual among webapps in sending essentially all of the
data required for the entire Zulip webapp in this single request,
which is part of why the Zulip webapp loads very quickly -- one only
Zulip is somewhat unusual among web apps in sending essentially all of the
data required for the entire Zulip web app in this single request,
which is part of why the Zulip web app loads very quickly -- one only
needs a single round trip aside from cacheable assets (avatars, images, JS,
CSS). Data on other users in the organization, streams, supported
emoji, custom profile fields, etc., is all included. The nice thing
@ -191,7 +191,7 @@ who have a lot of latency to the server.
There are only a few exceptions where we fetch data in a separate AJAX
request after page load:
* Message history is managed separately; this is why the Zulip webapp will
* Message history is managed separately; this is why the Zulip web app will
first render the entire site except for the middle panel, and then a
moment later render the middle panel (showing the message history).
* A few very rarely accessed data sets like [message edit
@ -219,7 +219,7 @@ We consider any organization having normal `page_params` fetch times
greater than a second to be a bug, and there is ongoing work to fix that.
It can help when thinking about this to imagine `page_params` as what
in another webapp would have been 25 or so HTTP GET requests, each
in another web app would have been 25 or so HTTP GET requests, each
fetching data of a given type (users, streams, custom emoji, etc.); in
Zulip, we just do all of those in a single API request. In the
future, we will likely move to a design that does much of the database
@ -234,14 +234,14 @@ of active optimization work.
Bulk requests for message content and metadata ([`GET
/messages`](https://zulip.com/api/get-messages)) account for ~3% of
total HTTP requests. The zulip webapp has a few major reasons it does
total HTTP requests. The zulip web app has a few major reasons it does
a large number of these requests:
* Most of these requests are from users clicking into different views
-- to avoid certain subtle bugs, Zulip's webapp currently fetches
-- to avoid certain subtle bugs, Zulip's web app currently fetches
content from the server even when it has the history for the
relevant stream/topic cached locally.
* When a browser opens the Zulip webapp, it will eventually fetch and
* When a browser opens the Zulip web app, it will eventually fetch and
cache in the browser all messages newer than the oldest unread
message in a non-muted context. This can be in total extremely
expensive for users with 10,000s of unread messages, resulting in a

6
docs/subsystems/presence.md
View File

@ -13,7 +13,7 @@ scalability problems for a team chat tool like Zulip.
There's a lot of performance-related details in the backend and
network protocol design that we won't get into here. The focus of
this is what one needs to know to correctly implement a Zulip client's
presence implementation (e.g. webapp, mobile app, terminal client, or
presence implementation (e.g. web app, mobile app, terminal client, or
other tool that's intended to represent whether a user is online and
using Zulip).
@ -23,11 +23,11 @@ requests contains a few parameters. The most important is "status",
which had 2 valid values:
* "active" -- this means the user has interacted with the client
recently. We use this for the "green" state in the webapp.
recently. We use this for the "green" state in the web app.
* "idle" -- the user has not interacted with the client recently.
This is important for the case where a user left a Zulip tab open on
their desktop at work and went home for the weekend. We use this
for the "orange" state in the webapp.
for the "orange" state in the web app.
The client receives in the response to that request a data set that,
for each user, contains their status and timestamp that we last heard

10
docs/subsystems/widgets.md
View File

@ -92,7 +92,7 @@ invoke, and they may share validation code.)
### Availability
The above commands are available for all Zulip servers
that use 1.9 or above. You must use the webapp client to
that use 1.9 or above. You must use the web app client to
get the features; other clients will send the messages
without any translation (e.g. "/day" will just be a message
that says "/day" if you use the mobile app).
@ -106,7 +106,7 @@ launch widgets by sending one of the following messages:
- /poll
- /todo
The webapp client provides the "widget experience" by
The web app client provides the "widget experience" by
default. Other clients just show raw messages like
"/poll", and should be adding support
for widgets soon.
@ -133,11 +133,11 @@ to the database). This data will also be included
in the normal Zulip message event payload. Clients
can choose to ignore the submessage-related data, in
which case they'll gracefully degrade to seeing "/poll".
Of course, the webapp client actually recognizes the
Of course, the web app client actually recognizes the
appropriate widgets.
The webapp client will next collect poll options and votes
from users. The webapp client has
The web app client will next collect poll options and votes
from users. The web app client has
code in `submessage.js` that dispatches events
to `widgetize.js`, which in turns sends events to
individual widgets. The widgets know how to render

2
docs/testing/philosophy.md
View File

@ -141,7 +141,7 @@ Some examples of this philosophy:
run, and produce this output".
In the Zulip context:
* Zulip uses the same API for our webapp as for our mobile clients and
* Zulip uses the same API for our web app as for our mobile clients and
third-party API clients, and most of our server tests are written
against the Zulip API.
* The tests for Zulip's incoming webhooks work by sending actual

2
docs/testing/testing-with-puppeteer.md
View File

@ -28,7 +28,7 @@ The Puppeteer tests use a real Chromium browser (powered by
[puppeteer](https://github.com/puppeteer/puppeteer)), connected to a
real Zulip development server. These are black-box tests: Steps in a
Puppeteer test are largely things one might do as a user of the Zulip
webapp, like "Type this key", "Wait until this HTML element
web app, like "Type this key", "Wait until this HTML element
appears/disappears", or "Click on this HTML element".
For example, this function might test the `x` keyboard shortcut to

2
docs/testing/testing.md
View File

@ -3,7 +3,7 @@
Zulip takes pride in its extensive, carefully designed test suites.
For example, `test-backend` runs a complete test suite (~98% test
coverage; 100% on core code) for the Zulip server in under a minute on
a fast laptop; very few webapps of similar scope can say something
a fast laptop; very few web apps of similar scope can say something
similar.
This page focused on the mechanics of running automated tests in a

8
docs/translating/translating.md
View File

@ -46,9 +46,9 @@ to any languages that you'd like to contribute to (or add new ones).
several resource files:
* `mobile.json` is for the iOS/Android mobile apps.
* `desktop.json` is for the parts of the Zulip desktop apps that
are not shared with the Zulip webapp.
are not shared with the Zulip web app.
* `django.po` and `translations.json` have strings for the next
major release of the Zulip server and webapp (which is what we
major release of the Zulip server and web app (which is what we
run on chat.zulip.org and Zulip Cloud).
* The variants of `django.po` and `translations.json` with names
starting with a version, like, `4-x--`, are strings for Zulip's
@ -121,7 +121,7 @@ There are a few ways to see your translations in the Zulip UI:
can view the login page in German using
`http://localhost:9991/de/login/`. This works for any part of the
Zulip UI, including portico (logged-out) pages.
* For Zulip's logged-in UI (i.e. the actual webapp), you can [pick the
* For Zulip's logged-in UI (i.e. the actual web app), you can [pick the
language](https://zulip.com/help/change-your-language) in the
Zulip UI.
* If your system has languages configured in your OS/browser, Zulip's
@ -193,7 +193,7 @@ capitalization in general. This means that:
- Incorrect: "Url"
The Zulip test suite enforces these capitalization guidelines in the
webapp codebase [in our test
web app codebase [in our test
suite](../testing/testing.html#other-test-suites)
(`./tools/check-capitalization`; `tools/lib/capitalization.py` has
some exclude lists, e.g. `IGNORED_PHRASES`).

2
static/js/activity.js
View File

@ -138,7 +138,7 @@ export function compute_active_status() {
// computer, and IDLE (aka orange circle) if the user might not
// be:
//
// * For the webapp, we just know whether this window has focus.
// * For the web app, we just know whether this window has focus.
// * For the electron desktop app, we also know whether the
// user is active or idle elsewhere on their system.
//

2
static/js/echo.js
View File

@ -124,7 +124,7 @@ export function build_display_recipient(message) {
// where the server might dynamically create users in
// response to messages being sent to their email address.
//
// TODO: It might be cleaner for the webapp for such
// TODO: It might be cleaner for the web app for such
// dynamic user creation to happen inside a separate API
// call when the pill is constructed, and then enforcing
// the requirement that we have an actual user object in

2
static/js/markdown_config.js
View File

@ -6,7 +6,7 @@ import * as user_groups from "./user_groups";
/*
This config is in a separate file for partly
tactical reasons. We want the webapp to
tactical reasons. We want the web app to
configure this one way, but we don't want to
share this code with mobile.

2
static/js/reload.js
View File

@ -243,7 +243,7 @@ export function initiate({
reload_state.set_state_to_pending();
// We're now planning to execute a reload of the browser, usually
// to get an updated version of the Zulip webapp code. Because in
// to get an updated version of the Zulip web app code. Because in
// most cases all browsers will be receiving this notice at the
// same or similar times, we need to randomize the time that we do
// this in order to avoid a thundering herd overloading the server.

4
static/js/util.js
View File

@ -284,12 +284,12 @@ export function clean_user_content_links(html) {
for (const elt of content.querySelectorAll("a")) {
// Ensure that all external links have target="_blank"
// rel="opener noreferrer". This ensures that external links
// never replace the Zulip webapp while also protecting
// never replace the Zulip web app while also protecting
// against reverse tabnapping attacks, without relying on the
// correctness of how Zulip's Markdown processor generates links.
//
// Fragment links, which we intend to only open within the
// Zulip webapp using our hashchange system, do not require
// Zulip web app using our hashchange system, do not require
// these attributes.
const href = elt.getAttribute("href");
let url;

2
static/shared/README.md
View File

@ -3,7 +3,7 @@ and are also incorporated by the Zulip mobile app.
Note that the deployment cycles are different:
* In the webapp, this code is deployed in the same way as the rest of
* In the web app, this code is deployed in the same way as the rest of
the web frontend: it's part of the server tree, and the browser
gets it from the server, so the client is always running the same
version the server just gave it.

2
static/shared/js/emoji.js
View File

@ -4,7 +4,7 @@ import _ from "lodash";
let emoji_codes = {};
// `emojis_by_name` is the central data source that is supposed to be
// used by every widget in the webapp for gathering data for displaying
// used by every widget in the web app for gathering data for displaying
// emojis. Emoji picker uses this data to derive data for its own use.
export const emojis_by_name = new Map();

4
static/styles/app_components.css
View File

@ -1,4 +1,4 @@
/* Reusable, object-oriented CSS base components for the Zulip webapp
/* Reusable, object-oriented CSS base components for the Zulip web app
(not included in the portico CSS) */
.flex {
@ -515,7 +515,7 @@ div.overlay {
color: hsl(0, 0%, 100%);
}
/* Implement the webapp's default-hidden convention for alert
/* Implement the web app's default-hidden convention for alert
elements. Portico pages lack this CSS and thus show them by
default. */
.alert {

2
static/styles/components.css
View File

@ -1,5 +1,5 @@
/* Reusable, object-oriented CSS base components for all Zulip pages
(both webapp and portico). */
(both web app and portico). */
.new-style {
label.checkbox {

2
templates/corporate/jobs.html
View File

@ -237,7 +237,7 @@
<li>You have the UI design skills to spot where a UI can be improved;
better yet, to design a better one.
</li>
<li>You have experience doing large codebase migrations in webapps in a way
<li>You have experience doing large codebase migrations in web apps in a way
that minimizes regressions.
</li>
<li>You have contributed to open-source projects; better yet, maintained a

2
templates/zerver/api/construct-narrow.md
View File

@ -7,7 +7,7 @@ API (most importantly, in the API for fetching messages).
It is simplest to explain the algorithm for encoding a search as a
narrow using a single example. Consider the following search query
(written as it would be entered in the Zulip webapp's search box). It
(written as it would be entered in the Zulip web app's search box). It
filters for messages sent on stream `announce`, not sent by
`iago@zulip.com`, and containing the phrase `cool sunglasses`:

2
templates/zerver/api/get-events.md
View File

@ -70,7 +70,7 @@ following error response:
{generate_code_example|/events:get|fixture(400)}
A compliant client will handle this error by re-initializing itself
(e.g. a Zulip webapp browser window will reload in this case).
(e.g. a Zulip web app browser window will reload in this case).
See [the /register endpoint docs](/api/register-queue) for details on how to
handle these correctly.

2
templates/zerver/api/register-queue.md
View File

@ -28,7 +28,7 @@ Once the server garbage-collects your event queue, the server will
with a code of `BAD_EVENT_QUEUE_ID` if you try to fetch events from
the event queue. Your software will need to handle that error
condition by re-initializing itself (e.g. this is what triggers your
browser reloading the Zulip webapp when your laptop comes back online
browser reloading the Zulip web app when your laptop comes back online
after being offline for more than 10 minutes).
When prototyping with this API, we recommend first calling `register`

2
templates/zerver/api/writing-bots.md
View File

@ -450,7 +450,7 @@ system and gives your test "dummy data" instead.
Some bots, such as [Giphy](
https://github.com/zulip/python-zulip-api/tree/master/zulip_bots/zulip_bots/bots/giphy),
depend on a third-party service, such as the Giphy webapp, in order to work. Because
depend on a third-party service, such as the Giphy web app, in order to work. Because
we want our test suite to be reliable and not add load to these third-party APIs, tests
for these services need to have "test fixtures": sample HTTP request/response pairs to
be used by the tests. You can specify which one to use in your test code using the

2
templates/zerver/features.html
View File

@ -273,7 +273,7 @@
<a class="feature-block" href="/help/create-your-organization-profile" target="_blank" rel="noopener noreferrer">
<h3>CUSTOM BRANDING</h3>
<p>
Use your logo instead of Zulip’s in the desktop and webapp.
Use your logo instead of Zulip’s in the desktop and web app.
</p>
</a>
<a class="feature-block" href="/integrations/communication" target="_blank" rel="noopener noreferrer">

2
templates/zerver/help/change-default-view.md
View File

@ -1,7 +1,7 @@
# Change default view
The default view in Zulip (i.e. what view you reach after logging in
to the Zulip webapp or hitting the `Esc` keyboard shortcut repeatedly)
to the Zulip web app or hitting the `Esc` keyboard shortcut repeatedly)
can be configured. By default, **Recent topics** is the default view;
the previous default, **All messages**, is also supported.

2
templates/zerver/help/gdpr-compliance.md
View File

@ -104,7 +104,7 @@ responding to a request from one of your users in relation to the
GDPR:
* A Zulip user can change their profile information, delete their
messages, uploaded files, etc., directly within the Zulip webapp.
messages, uploaded files, etc., directly within the Zulip web app.
* You can use the [organization users](/#organization/user-list-admin)
panel to deactivate users, edit or delete their account details,
etc.

6
tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
View File

@ -134,10 +134,10 @@ class BaseDocumentationSpider(scrapy.Spider):
return callback
def _make_requests(self, url: str) -> Iterator[Request]:
# These URLs are for Zulip's webapp, which with recent changes
# These URLs are for Zulip's web app, which with recent changes
# can be accessible without logging into an account. While we
# do crawl documentation served by the webapp (e.g. /help/),
# we don't want to crawl the webapp itself, so we exclude
# do crawl documentation served by the web app (e.g. /help/),
# we don't want to crawl the web app itself, so we exclude
# these.
if (
url in ["http://localhost:9981/", "http://localhost:9981"]

2
tools/setup/emoji/build_emoji
View File

@ -330,7 +330,7 @@ def setup_old_emoji_farm(
def generate_map_files(cache_path: str, emoji_catalog: Dict[str, List[str]]) -> None:
# This function generates the main data file about emoji that are
# consumed by the webapp, mobile apps, Markdown processor, etc.
# consumed by the web app, mobile apps, Markdown processor, etc.
names = emoji_names_for_picker(EMOJI_NAME_MAPS)
codepoint_to_name = generate_codepoint_to_name_map(EMOJI_NAME_MAPS)
name_to_codepoint = generate_name_to_codepoint_map(EMOJI_NAME_MAPS)

2
zerver/lib/event_schema.py
View File

@ -4,7 +4,7 @@
# By policy, every event generated by Zulip's API should be validated
# by a test in test_events.py with a schema checker here (which is
# validated, in turn, against the OpenAPI documentation for GET
# /events in zulip.yaml and the fixtures used by the Zulip webapp
# /events in zulip.yaml and the fixtures used by the Zulip web app
# frontend).
#
# See https://zulip.readthedocs.io/en/latest/subsystems/events-system.html

6
zerver/lib/events.py
View File

@ -107,7 +107,7 @@ def fetch_initial_state_data(
include_streams: bool = True,
) -> Dict[str, Any]:
"""When `event_types` is None, fetches the core data powering the
webapp's `page_params` and `/api/v1/register` (for mobile/terminal
web app's `page_params` and `/api/v1/register` (for mobile/terminal
apps). Can also fetch a subset as determined by `event_types`.
The user_profile=None code path is used for logged-out public
@ -422,7 +422,7 @@ def fetch_initial_state_data(
if want("stream"):
if include_streams:
# The webapp doesn't use the data from here; instead,
# The web app doesn't use the data from here; instead,
# it uses data from state["subscriptions"] and other
# places.
if user_profile is not None:
@ -430,7 +430,7 @@ def fetch_initial_state_data(
user_profile, include_all_active=user_profile.is_realm_admin
)
else:
# TODO: This line isn't used by the webapp because it
# TODO: This line isn't used by the web app because it
# gets these data via the `subscriptions` key; it will
# be used when the mobile apps support logged-out
# access.

4
zerver/lib/test_classes.py
View File

@ -199,7 +199,7 @@ Output:
# An API request; use mobile as the default user agent
default_user_agent = "ZulipMobile/26.22.145 (iOS 10.3.1)"
else:
# A webapp request; use a browser User-Agent string.
# A web app request; use a browser User-Agent string.
default_user_agent = (
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
+ "AppleWebKit/537.36 (KHTML, like Gecko) "
@ -494,7 +494,7 @@ Output:
self.assert_json_error(result, assert_json_error_msg)
def _get_page_params(self, result: HttpResponse) -> Dict[str, Any]:
"""Helper for parsing page_params after fetching the webapp's home view."""
"""Helper for parsing page_params after fetching the web app's home view."""
doc = lxml.html.document_fromstring(result.content)
[div] = doc.xpath("//div[@id='page-params']")
page_params_json = div.get("data-params")

2
zerver/lib/widget.py
View File

@ -46,7 +46,7 @@ def get_extra_data_from_widget_type(content: str, widget_type: Optional[str]) ->
def do_widget_post_save_actions(send_request: SendMessageRequest) -> None:
"""
This code works with the webapp; mobile and other
This code works with the web app; mobile and other
clients should also start supporting this soon.
"""
message_content = send_request.message.content

6
zerver/models.py
View File

@ -545,7 +545,7 @@ class Realm(models.Model):
)
icon_version: int = models.PositiveSmallIntegerField(default=1)
# Logo is the horizontal logo we show in top-left of webapp navbar UI.
# Logo is the horizontal logo we show in top-left of web app navbar UI.
LOGO_DEFAULT = "D"
LOGO_UPLOADED = "U"
LOGO_SOURCES = (
@ -1300,7 +1300,7 @@ class UserProfile(AbstractBaseUser, PermissionsMixin):
# UI setting controlling Zulip's behavior of demoting in the sort
# order and graying out streams with no recent traffic. The
# default behavior, automatic, enables this behavior once a user
# is subscribed to 30+ streams in the webapp.
# is subscribed to 30+ streams in the web app.
DEMOTE_STREAMS_AUTOMATIC = 1
DEMOTE_STREAMS_ALWAYS = 2
DEMOTE_STREAMS_NEVER = 3
@ -3080,7 +3080,7 @@ class UserPresence(models.Model):
# The user was actively using this Zulip client as of `timestamp` (i.e.,
# they had interacted with the client recently). When the timestamp is
# itself recent, this is the green "active" status in the webapp.
# itself recent, this is the green "active" status in the web app.
ACTIVE = 1
# There had been no user activity (keyboard/mouse/etc.) on this client

10
zerver/openapi/zulip.yaml
View File

@ -1757,7 +1757,7 @@ paths:
the current user have changed (E.g. because the user dismissed one).
Clients that feature a similar tutorial experience to the Zulip
webapp may want to handle these events.
web app may want to handle these events.
properties:
id:
$ref: "#/components/schemas/EventIdSchema"
@ -1873,7 +1873,7 @@ paths:
navigation and compose box state in response to the edit. For
example, if the user was previously in topic narrow, and the
topic was edited with `change_later` or `change_all`, the Zulip
webapp will automatically navigate to the new topic narrow.
web app will automatically navigate to the new topic narrow.
Similarly, a message being composed to the old topic should
have its recipient changed to the new topic.
@ -8085,7 +8085,7 @@ paths:
Present if `update_display_settings` is present in `fetch_event_types`.
Whether the user has chosen for the userlist to be displayed
on the left side of the screen (for desktop app and webapp) in narrow
on the left side of the screen (for desktop app and web app) in narrow
windows.
See [PATCH /settings/display](/api/update-display-settings)
@ -9550,7 +9550,7 @@ paths:
in: query
description: |
Whether to use the [maximum available screen width](/help/enable-full-width-display)
for the webapp's center panel (message feed, recent topics) on wide screens.
for the web app's center panel (message feed, recent topics) on wide screens.
schema:
type: boolean
example: true
@ -9608,7 +9608,7 @@ paths:
in: query
description: |
The [default view](/help/change-default-view) used when opening a new
Zulip webapp window or hitting the `Esc` keyboard shortcut repeatedly.
Zulip web app window or hitting the `Esc` keyboard shortcut repeatedly.
* "recent_topics" - Recent topics view
* "all_messages" - All messages view

2
zerver/tests/test_auth_backends.py
View File

@ -918,7 +918,7 @@ class SocialAuthBase(DesktopFlowTestingLib, ZulipTestCase):
"Continue to registration" if you try to log in using an
account that doesn't exist but is allowed to sign up.
* next: Parameter passed through in production authentication
to redirect the user to (e.g.) the specific page in the webapp
to redirect the user to (e.g.) the specific page in the web app
that they clicked a link to before being presented with the login
page.
* expect_choose_email_screen: Some social auth backends, like

2
zerver/tests/test_messages.py
View File

@ -55,7 +55,7 @@ class MissedMessageTest(ZulipTestCase):
set_presence(hamlet, "iPhone", ago=5000)
assert_missing([hamlet.id])
set_presence(hamlet, "webapp", ago=15)
set_presence(hamlet, "website", ago=15)
assert_missing([])
message_type = "private"

2
zerver/views/auth.py
View File

@ -142,7 +142,7 @@ def maybe_send_to_registration(
# result in being logged into the app to persist if the user makes
# mistakes while trying to authenticate (E.g. clicks the wrong
# Google account, hits back, etc.) during a given browser session,
# rather than just logging into the webapp in the target browser.
# rather than just logging into the web app in the target browser.
#
# We can't use our usual pre-account-creation state storage
# approach of putting something in PreregistrationUser, because

2
zerver/views/message_fetch.py
View File

@ -918,7 +918,7 @@ def parse_anchor_value(anchor_val: Optional[str], use_first_unread_anchor: bool)
# We don't use `.isnumeric()` to support negative numbers for
# anchor. We don't recommend it in the API (if you want the
# very first message, use 0 or 1), but it used to be supported
# and was used by the webapp, so we need to continue
# and was used by the web app, so we need to continue
# supporting it for backwards-compatibility
anchor = int(anchor_val)
if anchor < 0:

4
zerver/views/presence.py
View File

@ -25,7 +25,7 @@ from zerver.models import (
def get_presence_backend(
request: HttpRequest, user_profile: UserProfile, user_id_or_email: str
) -> HttpResponse:
# This isn't used by the webapp; it's available for API use by
# This isn't used by the web app; it's available for API use by
# bots and other clients. We may want to add slim_presence
# support for it (or just migrate its API wholesale) later.
@ -127,7 +127,7 @@ def update_active_status_backend(
def get_statuses_for_realm(request: HttpRequest, user_profile: UserProfile) -> HttpResponse:
# This isn't used by the webapp; it's available for API use by
# This isn't used by the web app; it's available for API use by
# bots and other clients. We may want to add slim_presence
# support for it (or just migrate its API wholesale) later.
return json_success(get_presence_response(user_profile, slim_presence=False))

4
zproject/urls.py
View File

@ -398,7 +398,7 @@ v1_api_and_json_patterns = [
POST=(
mark_hotspot_as_read,
# This endpoint is low priority for documentation as
# it is part of the webapp-specific tutorial.
# it is part of the web app-specific tutorial.
{"intentionally_undocumented"},
),
),
@ -472,7 +472,7 @@ v1_api_and_json_patterns = [
# report -> zerver.views.report
#
# These endpoints are for internal error/performance reporting
# from the browser to the webapp, and we don't expect to ever
# from the browser to the web app, and we don't expect to ever
# include in our API documentation.
rest_path(
"report/error",