mirror of https://github.com/zulip/zulip.git
docs: Fix some typos in documentation (most of them found and fixed by codespell).
Signed-off-by: Stefan Weil <sw@weilnetz.de>
This commit is contained in:
parent
5e47f2975e
commit
c220b971ae
|
@ -199,7 +199,7 @@ materials](https://developers.google.com/open-source/gsoc/resources/manual).
|
|||
necessary to test a feature.
|
||||
|
||||
- Make a plan for how to create a series of small (<100LOC) commits that are
|
||||
each safely mergable and move you towards your goal. Often this ends up
|
||||
each safely mergeable and move you towards your goal. Often this ends up
|
||||
happening through first doing a hacky attempt to hooking together the
|
||||
feature, with reading and print statements as part of the effort, to
|
||||
identify any refactoring needed or tests you want to write to help make sure
|
||||
|
|
|
@ -38,7 +38,7 @@ example; accessible live
|
|||
[here](https://zulipchat.com/api/render-message) or in the development
|
||||
environment at `http://localhost:9991/api/render-message`).
|
||||
|
||||
We highly recommend looking at those resouces while reading this page.
|
||||
We highly recommend looking at those resources while reading this page.
|
||||
|
||||
If you look at the documentation for existing endpoints, you'll notice
|
||||
that a typical endpoint's documentation is divided into four sections:
|
||||
|
|
|
@ -96,7 +96,7 @@ allows .." rather than "we also allow ..". `You` is ok and used liberally.
|
|||
## Features
|
||||
|
||||
Zulip's Markdown processor allows you to include several special features in
|
||||
your documentation to help improve its readibility:
|
||||
your documentation to help improve its readability:
|
||||
|
||||
* Since raw HTML is supported in Markdown, you can include arbitrary
|
||||
HTML/CSS in your documentation as needed.
|
||||
|
|
|
@ -116,7 +116,7 @@ CI will run tests for new refs you push to GitHub and email you the outcome
|
|||
|
||||
Running CI against your fork can help save both your and the
|
||||
Zulip maintainers time by making it easy to test a change fully before
|
||||
submitting a pull request. We generally recommend a worfklow where as
|
||||
submitting a pull request. We generally recommend a workflow where as
|
||||
you make changes, you use a fast edit-refresh cycle running individual
|
||||
tests locally until your changes work. But then once you've gotten
|
||||
the tests you'd expect to be relevant to your changes working, push a
|
||||
|
|
|
@ -88,7 +88,7 @@ From https://github.com/zulip/zulip
|
|||
Branch review-1913 set up to track remote branch master from upstream.
|
||||
Switched to a new branch 'review-1913'
|
||||
+ git reset --hard FETCH_HEAD
|
||||
HEAD is now at 99aa2bf Add provision.py fails issue in common erros
|
||||
HEAD is now at 99aa2bf Add provision.py fails issue in common errors
|
||||
+ git pull --rebase
|
||||
Current branch review-1913 is up to date.
|
||||
```
|
||||
|
|
|
@ -277,7 +277,7 @@ lose the setting and need to re-enable it.
|
|||
- Replaced title attributes with nice tooltips in the message feed and
|
||||
buddy list.
|
||||
- Fixed incorrect caching settings for the Zulip API, which could result
|
||||
in browers appearing to display old content or remark messages unread.
|
||||
in browsers appearing to display old content or remark messages unread.
|
||||
- Fixed a bug that prevented sending mobile push notifications when the
|
||||
user was recently online via the mobile app.
|
||||
- Fixed buggy handling of LaTeX in quote-and-reply.
|
||||
|
@ -618,7 +618,7 @@ Zulip installations; it has minimal changes for existing servers.
|
|||
- Fixed confusing intermediate states of group PMs online indicators.
|
||||
- Fixed several subtle unread count corner case bugs.
|
||||
- Fixed several installer issues to make it easier to Dockerize Zulip.
|
||||
- Fixed several subtle issues with both the LDAP/Active Direcotry
|
||||
- Fixed several subtle issues with both the LDAP/Active Directory
|
||||
integration and its documentation, making it much easier to setup.
|
||||
- Fixed several minor bugs and otherwise optimized search typeahead.
|
||||
- Fixed a bad nginx configuration interaction with servers that have
|
||||
|
|
|
@ -241,7 +241,7 @@ server {
|
|||
```
|
||||
|
||||
Don't forget to update `server_name`, `ssl_certificate`,
|
||||
`ssl_certificate_key` and `proxy_pass` with propper values.
|
||||
`ssl_certificate_key` and `proxy_pass` with proper values.
|
||||
|
||||
[nginx-proxy-config]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-common/proxy
|
||||
[nginx-proxy-longpolling-config]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-common/proxy_longpolling
|
||||
|
|
|
@ -157,7 +157,7 @@ step, to do the migration.
|
|||
this command runs on 6 parallel processes, since uploading is a
|
||||
latency-sensitive operation. You can control this parameter using
|
||||
the `--processes` option.
|
||||
3. Once the transer script compltes, disable `LOCAL_UPLOADS_DIR`, and
|
||||
3. Once the transfer script completes, disable `LOCAL_UPLOADS_DIR`, and
|
||||
restart your server (continuing the last few steps of the S3
|
||||
backend setup instructions).
|
||||
|
||||
|
|
|
@ -93,7 +93,7 @@ Other notes:
|
|||
Zulip's email templates live under `templates/zerver/emails`. Email
|
||||
templates are a messy problem, because on the one hand, you want nice,
|
||||
readable markup and styling, but on the other, email clients have very
|
||||
limited CSS support and generaly require us to inject any CSS we're
|
||||
limited CSS support and generally require us to inject any CSS we're
|
||||
using in the emails into the email as inline styles. And then you
|
||||
also need both plain-text and HTML emails. We solve these problems
|
||||
using a combination of the
|
||||
|
|
|
@ -99,7 +99,7 @@ The following set of considerations is not comprehensive, but has a few
|
|||
principles that were applied to the current set of names. We use (strong),
|
||||
(medium), and (weak) denote how strong a consideration it is.
|
||||
|
||||
* Even with over 1000 symbols, emoji feels suprisingly sparse as a language,
|
||||
* Even with over 1000 symbols, emoji feels surprisingly sparse as a language,
|
||||
and more often than not, if you search for something, you don't find an
|
||||
appropriate emoji for it. So a primary goal for our set of names is to
|
||||
maximize the number of situations in which the user finds an emoji that
|
||||
|
|
|
@ -211,7 +211,7 @@ request; the logic is in `zerver/views/events_register.py` and
|
|||
* Finally, Django "applies" the events (see the `apply_events`
|
||||
function) to the initial state that it fetched. E.g. for a name
|
||||
change event, it finds the user data in the `realm_user` data
|
||||
struture, and updates it to have the new name.
|
||||
structure, and updates it to have the new name.
|
||||
|
||||
### Testing
|
||||
|
||||
|
|
|
@ -152,7 +152,7 @@ are written in the Sass extension of CSS (with the scss syntax), they
|
|||
are converted from plain CSS and we have yet to take full advantage of
|
||||
the features Sass offers. We use Webpack to transpile and build JS
|
||||
and CSS bundles that the browser can understand, one for each entry
|
||||
points specifed in `tools/webpack.assets.json`; source maps are
|
||||
points specified in `tools/webpack.assets.json`; source maps are
|
||||
generated in the process for better debugging experience.
|
||||
|
||||
In development mode, bundles are built and served on the fly using
|
||||
|
@ -239,7 +239,7 @@ server is restarted, files are copied into that directory.
|
|||
|
||||
### CommonJS/Typescript modules
|
||||
|
||||
Webpack provides seemless interoperability between different module
|
||||
Webpack provides seamless interoperability between different module
|
||||
systems such as CommonJS, AMD and ES6. Our JS files are written in the
|
||||
CommonJS format, which specifies public functions and variables as
|
||||
properties of the special `module.exports` object. We also currently
|
||||
|
|
|
@ -40,7 +40,7 @@ about that data structure:
|
|||
timestamp) pair. E.g. a user who last used Zulip 1 week ago will
|
||||
have a timestamp of 1 week ago and a status of "active". Why?
|
||||
Because this correctly handles the race conditions. For example, if
|
||||
the threshhold for displaying a user as "offline" was 5 minutes
|
||||
the threshold for displaying a user as "offline" was 5 minutes
|
||||
since the user was last online, the client can at any time
|
||||
accurately compute whether that user is offline (even if the last
|
||||
data from the server was 45 seconds ago, and the user was last
|
||||
|
|
|
@ -147,7 +147,7 @@ to undo without going to backups.
|
|||
If you follow the processes described above, `tools/provision` and
|
||||
`tools/test-backend` should detect any changes to the declared
|
||||
migrations and run migrations on (`./manage.py migrate`) or rebuild
|
||||
the relevant database automatially as appropriate.
|
||||
the relevant database automatically as appropriate.
|
||||
|
||||
Developing migrations can result in manual fiddling that leads to a
|
||||
broken database state, however. For those situations, we have
|
||||
|
|
|
@ -294,7 +294,7 @@ a field called `reply` (in `choices`) as the content
|
|||
of the message reply. Then the bot sees the reply
|
||||
and grades the answer using ordinary chat-bot coding.
|
||||
|
||||
The beautiful thing is that any thrid party developer
|
||||
The beautiful thing is that any third party developer
|
||||
can enhance bots that are similar to the **trivia_quiz**
|
||||
bot without touching any Zulip code, because **zforms**
|
||||
are completely generic.
|
||||
|
|
|
@ -79,7 +79,7 @@ create the directory mentioned in `working_directory` and all the
|
|||
steps are be run from here.
|
||||
|
||||
The `steps` section describes describes everything: fetching the Zulip
|
||||
code, provisioning, fetching catched data, running tests and uploading
|
||||
code, provisioning, fetching caught data, running tests and uploading
|
||||
coverage reports. The steps with prefix `*` reference aliases, which
|
||||
are defined in the `aliases` section at the top of the file.
|
||||
|
||||
|
|
|
@ -492,7 +492,7 @@ Do these tasks as Cordelia.
|
|||
- Turn on/off "Enable desktop notifications for new streams" and test.
|
||||
(We may eliminate this option soon.)
|
||||
|
||||
### Keyboard Shorcuts ###
|
||||
### Keyboard Shortcuts ###
|
||||
|
||||
We mostly test keyboard shortcuts as part of other tasks.
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ any large software project will eventually have its test suite rot
|
|||
into one that is slow, unreliable, untrustworthy, and hated. We aim
|
||||
for Zulip to avoid that fate.
|
||||
|
||||
So we consider it essential to maintaing every automated test suite
|
||||
So we consider it essential to maintaining every automated test suite
|
||||
setup in a way where it is fast and reliable (tests pass both in CI
|
||||
and locally if there are no problems with the developer's changes).
|
||||
|
||||
|
|
|
@ -96,7 +96,7 @@ for writing Casper tests in addition to the debugging notes below:
|
|||
code to wait for the right events. Before essentially every action
|
||||
you take on the page, you'll want to use `waitUntilVisible`,
|
||||
`waitWhileVisible`, or a similar function to make sure the page
|
||||
or elemant is ready before you interact with it. For instance, if
|
||||
or element is ready before you interact with it. For instance, if
|
||||
you want to click a button that you can select via `#btn-submit`,
|
||||
and then check that it causes `success-elt` to appear, you'll want
|
||||
to write something like:
|
||||
|
|
|
@ -77,7 +77,7 @@ Additionally, Zulip also has about a dozen smaller tests suites:
|
|||
details on the system this is verifying.
|
||||
- `tools/check-capitalization`: Checks whether translated strings (aka
|
||||
user-facing strings) correctly follow Zulip's capitalization
|
||||
conventions. This requires some maintainance of an exclude list
|
||||
conventions. This requires some maintenance of an exclude list
|
||||
(`tools.lib.capitalization.IGNORED_PHRASES`) of proper nouns
|
||||
mentioned in the Zulip project, but helps a lot in avoiding new
|
||||
strings being added that don't match our style.
|
||||
|
|
|
@ -38,7 +38,7 @@ the reader and remember to capitalize *Du*.
|
|||
For instructions, try to use the imperative (e.g. *"Gehe auf die Seite"* -
|
||||
*"Go to the page"*) instead of constructions with auxiliary verbs
|
||||
(e.g. *"Du musst auf die Seite ... gehen"* - *"You have to go the page ..."*).
|
||||
This keeps the phrases short, less stiff and avoids unnecessary addressings
|
||||
This keeps the phrases short, less stiff and avoids unnecessary addressing
|
||||
of the reader.
|
||||
|
||||
### Rules for labels
|
||||
|
|
|
@ -38,7 +38,7 @@
|
|||
* settings - **настройки**
|
||||
* invalid - **неверный**
|
||||
* incorrect - **неправильный**
|
||||
* uknown - **неизвестный**
|
||||
* unknown - **неизвестный**
|
||||
* account - **учетная запись**
|
||||
* subdomain - **поддомен**
|
||||
* API key - **API-ключ**
|
||||
|
|
|
@ -117,7 +117,7 @@ There are a few ways to see your translations in the Zulip UI:
|
|||
print(response.content)
|
||||
```
|
||||
|
||||
This can occassionally be useful for debugging.
|
||||
This can occasionally be useful for debugging.
|
||||
|
||||
### Translation style guides
|
||||
|
||||
|
|
|
@ -527,7 +527,7 @@ In frontend, we have split the `property_types` into three objects:
|
|||
like who can join the organization and whether normal users can
|
||||
create streams or upload custom emoji.
|
||||
|
||||
Once you've determined wheter the new setting belongs, the next step
|
||||
Once you've determined whether the new setting belongs, the next step
|
||||
is to find the right subsection of that page to put the setting
|
||||
in. For example in this case of `mandatory_topics` it will lie in
|
||||
"Message feed" (`msg_feed`) subsection.
|
||||
|
|
Loading…
Reference in New Issue