Merge branch 'develop' into germain-gg/25884
This commit is contained in:
Johannes Marbach
GitHub
commit
1575832766
175 changed files with 18075 additions and 15712 deletions
41
docs/SUMMARY.md
Normal file
41
docs/SUMMARY.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
# Summary
|
||||
|
||||
- [Introduction](../README.md)
|
||||
|
||||
# Usage
|
||||
|
||||
- [Betas](betas.md)
|
||||
- [Labs](labs.md)
|
||||
|
||||
# Setup
|
||||
|
||||
- [Install](install.md)
|
||||
- [Config](config.md)
|
||||
- [Custom home page](custom-home.md)
|
||||
- [Kubernetes](kubernetes.md)
|
||||
- [Jitsi](jitsi.md)
|
||||
- [Encryption](e2ee.md)
|
||||
|
||||
# Build
|
||||
|
||||
- [Customisations](customisations.md)
|
||||
- [Modules](modules.md)
|
||||
- [Native Node modules](native-node-modules.md)
|
||||
|
||||
# Contribution
|
||||
|
||||
- [Choosing an issue](choosing-an-issue.md)
|
||||
- [Translation](translating.md)
|
||||
- [Netlify builds](pr-previews.md)
|
||||
- [Code review](review.md)
|
||||
|
||||
# Development
|
||||
|
||||
- [App load order](app-load.md)
|
||||
- [Translation](translating-dev.md)
|
||||
- [Theming](theming.md)
|
||||
- [Memory profiling](memory-profiles-and-leaks.md)
|
||||
- [Jitsi](jitsi-dev.md)
|
||||
- [Feature flags](feature-flags.md)
|
||||
- [OIDC and delegated authentication](oidc.md)
|
||||
- [Release Process](release.md)
|
||||
137
docs/app-load.md
137
docs/app-load.md
|
|
@ -4,78 +4,67 @@
|
|||
been kept untouched for posterity.
|
||||
|
||||
Old slow flow:
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A1(((load_modernizr))) --> B
|
||||
A2((rageshake)) --> B
|
||||
B(((skin))) --> C
|
||||
C(((olm))) --> D
|
||||
D{mobile} --> E
|
||||
E((config)) --> F
|
||||
F((i18n)) --> G
|
||||
style F stroke:lime
|
||||
G(((theme))) --> H
|
||||
H(((modernizr))) --> app
|
||||
style H stroke:red
|
||||
```
|
||||
|
||||
Current more parallel flow:
|
||||
|
||||
|
||||
<details><summary>Code</summary>
|
||||
<p>
|
||||
<pre><code>
|
||||
digraph G {
|
||||
node [shape=box];
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph index.ts
|
||||
style index.ts stroke:orange
|
||||
|
||||
subgraph cluster_0 {
|
||||
color=orange;
|
||||
node [style=filled];
|
||||
label = "index.ts";
|
||||
A[/rageshake/] --> B{mobile}
|
||||
B-- No -->C1(.)
|
||||
B-- Yes -->C2((redirect))
|
||||
C1 --> D[/olm/] --> R
|
||||
C1 --> E[platform] --> F[/config/]
|
||||
F --> G1[/skin/]
|
||||
F --> R
|
||||
G1 --> H
|
||||
G1 --> R
|
||||
F --> G2[/theme/]
|
||||
G2 --> H
|
||||
G2 --> R
|
||||
F --> G3[/i18n/]
|
||||
G3 --> H
|
||||
G3 --> R
|
||||
H{modernizr}-- No --> J((incompatible))-- user ignore --> R
|
||||
H-- Yes --> R
|
||||
|
||||
entrypoint, s0, ready [shape=point];
|
||||
rageshake, config, i18n, theme, skin, olm [shape=parallelogram];
|
||||
mobile [shape=diamond, label="mobile"];
|
||||
modernizr [shape=diamond];
|
||||
redirect, incompatible [shape=egg];
|
||||
linkStyle 0,7,9,11,12,14,15 stroke:blue;
|
||||
linkStyle 4,8,10,13,16 stroke:red;
|
||||
end
|
||||
|
||||
entrypoint -> rageshake;
|
||||
rageshake -> mobile [color=blue];
|
||||
mobile -> s0 [label="No"];
|
||||
mobile -> redirect [label="Yes"];
|
||||
R>ready] --> 2A
|
||||
style R stroke:gray
|
||||
|
||||
s0 -> platform;
|
||||
s0 -> olm;
|
||||
platform -> config;
|
||||
subgraph init.tsx
|
||||
style init.tsx stroke:lime
|
||||
2A[loadApp] --> 2B[matrixchat]
|
||||
end
|
||||
|
||||
config -> i18n [color=blue];
|
||||
config -> theme [color=blue];
|
||||
config -> skin [color=blue];
|
||||
|
||||
i18n -> modernizr [color=blue];
|
||||
theme -> modernizr [color=blue];
|
||||
skin -> modernizr [color=blue];
|
||||
|
||||
modernizr -> ready [label="Yes"];
|
||||
modernizr -> incompatible [label="No"];
|
||||
incompatible -> ready [label="user ignore"];
|
||||
|
||||
olm -> ready [color=red];
|
||||
config -> ready [color=red];
|
||||
skin -> ready [color=red];
|
||||
theme -> ready [color=red];
|
||||
i18n -> ready [color=red];
|
||||
|
||||
}
|
||||
|
||||
subgraph cluster_1 {
|
||||
color = green;
|
||||
node [style=filled];
|
||||
label = "init.tsx";
|
||||
|
||||
ready -> loadApp;
|
||||
loadApp -> matrixchat;
|
||||
|
||||
}
|
||||
}
|
||||
</code></pre>
|
||||
|
||||
</p>
|
||||
</details>
|
||||
```
|
||||
|
||||
Key:
|
||||
|
||||
- Parallelogram: async/await task
|
||||
- Box: sync task
|
||||
- Diamond: conditional branch
|
||||
- Egg: user interaction
|
||||
- Circle: user interaction
|
||||
- Blue arrow: async task is allowed to settle but allowed to fail
|
||||
- Red arrow: async task success is asserted
|
||||
|
||||
|
|
@ -86,4 +75,34 @@ Notes:
|
|||
- Everything is awaited to be settled before the Modernizr check, to allow it to make use of things like i18n if they are successful.
|
||||
|
||||
Underlying dependencies:
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A((rageshake))
|
||||
B{mobile}
|
||||
C((config))
|
||||
D(((olm)))
|
||||
E((i18n))
|
||||
F(((load_modernizr)))
|
||||
G(((modernizr)))
|
||||
H(((skin)))
|
||||
I(((theme)))
|
||||
X[app]
|
||||
|
||||
A --> G
|
||||
A --> B
|
||||
A-- assert -->X
|
||||
F --> G --> X
|
||||
G --> H --> X
|
||||
C --> I --> X
|
||||
C --> E --> X
|
||||
E --> G
|
||||
B --> C-- assert -->X
|
||||
B --> D --> X
|
||||
|
||||
style X stroke:red
|
||||
style G stroke:red
|
||||
style E stroke:lime
|
||||
linkStyle 0,11 stroke:yellow;
|
||||
linkStyle 2,13 stroke:red;
|
||||
```
|
||||
|
|
|
|||
|
|
@ -54,8 +54,8 @@ One of the following options **must** be supplied:
|
|||
being optional.
|
||||
|
||||
If both `default_server_config` and `default_server_name` are used, Element will try to look up the connection
|
||||
infomation using `.well-known`, and if that fails, take `default_server_config` as the homeserver connection
|
||||
infomation.
|
||||
information using `.well-known`, and if that fails, take `default_server_config` as the homeserver connection
|
||||
information.
|
||||
|
||||
## Labs flags
|
||||
|
||||
|
|
@ -139,7 +139,7 @@ complete re-branding/private labeling, a more personalised experience can be ach
|
|||
configuration found in the well-known location is used instead.
|
||||
10. `welcome_user_id`: An optional user ID to start a DM with after creating an account. Defaults to nothing (no DM created).
|
||||
11. `custom_translations_url`: An optional URL to allow overriding of translatable strings. The JSON file must be in a format of
|
||||
`{"affected string": {"languageCode": "new string"}}`. See https://github.com/matrix-org/matrix-react-sdk/pull/7886 for details.
|
||||
`{"affected|translation|key": {"languageCode": "new string"}}`. See https://github.com/matrix-org/matrix-react-sdk/pull/7886 for details.
|
||||
12. `branding`: Options for configuring various assets used within the app. Described in more detail down below.
|
||||
13. `embedded_pages`: Further optional URLs for various assets used within the app. Described in more detail down below.
|
||||
14. `disable_3pid_login`: When `false` (default), **enables** the options to log in with email address or phone number. Set to
|
||||
|
|
@ -355,6 +355,8 @@ If you run your own rageshake server to collect bug reports, the following optio
|
|||
2. `uisi_autorageshake_app`: If a user has enabled the "automatically send debug logs on decryption errors" flag, this option will be sent
|
||||
alongside the rageshake so the rageshake server can filter them by app name. By default, this will be `element-auto-uisi`
|
||||
(in contrast to other rageshakes submitted by the app, which use `element-web`).
|
||||
3. `existing_issues_url`: URL for where to find existing issues.
|
||||
4. `new_issue_url`: URL for where to submit new issues.
|
||||
|
||||
If you would like to use [Sentry](https://sentry.io/) for rageshake data, add a `sentry` object to your config with the following values:
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ When `force_disable` is true:
|
|||
- any `io.element.e2ee.default` value will be disregarded.
|
||||
|
||||
Note: If the server is configured to forcibly enable encryption for some or all rooms,
|
||||
this behaviour will be overriden.
|
||||
this behaviour will be overridden.
|
||||
|
||||
# Secure backup
|
||||
|
||||
|
|
|
|||
78
docs/install.md
Normal file
78
docs/install.md
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
# Installing Element Web
|
||||
|
||||
**Familiarise yourself with the [Important Security Notes](../README.md#important-security-notes) before starting, they apply to all installation methods.**
|
||||
|
||||
_Note: that for the security of your chats will need to serve Element over HTTPS.
|
||||
Major browsers also do not allow you to use VoIP/video chats over HTTP, as WebRTC is only usable over HTTPS.
|
||||
There are some exceptions like when using localhost, which is considered a [secure context](https://developer.mozilla.org/docs/Web/Security/Secure_Contexts) and thus allowed._
|
||||
|
||||
## Release tarball
|
||||
|
||||
1. Download the latest version from <https://github.com/vector-im/element-web/releases>
|
||||
1. Untar the tarball on your web server
|
||||
1. Move (or symlink) the `element-x.x.x` directory to an appropriate name
|
||||
1. Configure the correct caching headers in your webserver (see below)
|
||||
1. Configure the app by copying `config.sample.json` to `config.json` and
|
||||
modifying it. See the [configuration docs](docs/config.md) for details.
|
||||
1. Enter the URL into your browser and log into Element!
|
||||
|
||||
Releases are signed using gpg and the OpenPGP standard,
|
||||
and can be checked against the public key located at <https://packages.element.io/element-release-key.asc>.
|
||||
|
||||
## Debian package
|
||||
|
||||
Element Web is now also available as a Debian package for Debian and Ubuntu based systems.
|
||||
|
||||
```shell
|
||||
sudo apt install -y wget apt-transport-https
|
||||
sudo wget -O /usr/share/keyrings/element-io-archive-keyring.gpg https://packages.element.io/debian/element-io-archive-keyring.gpg
|
||||
echo "deb [signed-by=/usr/share/keyrings/element-io-archive-keyring.gpg] https://packages.element.io/debian/ default main" | sudo tee /etc/apt/sources.list.d/element-io.list
|
||||
sudo apt update
|
||||
sudo apt install element-web
|
||||
```
|
||||
|
||||
Configure the app by modifying `/etc/element-web/config.json`. See the [configuration docs](docs/config.md) for details.
|
||||
|
||||
## Docker
|
||||
|
||||
The Docker image can be used to serve element-web as a web server. The easiest way to use
|
||||
it is to use the prebuilt image:
|
||||
|
||||
```bash
|
||||
docker run -p 80:80 vectorim/element-web
|
||||
```
|
||||
|
||||
To supply your own custom `config.json`, map a volume to `/app/config.json`. For example,
|
||||
if your custom config was located at `/etc/element-web/config.json` then your Docker command
|
||||
would be:
|
||||
|
||||
```bash
|
||||
docker run -p 80:80 -v /etc/element-web/config.json:/app/config.json vectorim/element-web
|
||||
```
|
||||
|
||||
To build the image yourself:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/vector-im/element-web.git element-web
|
||||
cd element-web
|
||||
git checkout master
|
||||
docker build .
|
||||
```
|
||||
|
||||
If you're building a custom branch, or want to use the develop branch, check out the appropriate
|
||||
element-web branch and then run:
|
||||
|
||||
```bash
|
||||
docker build -t \
|
||||
--build-arg USE_CUSTOM_SDKS=true \
|
||||
--build-arg REACT_SDK_REPO="https://github.com/matrix-org/matrix-react-sdk.git" \
|
||||
--build-arg REACT_SDK_BRANCH="develop" \
|
||||
--build-arg JS_SDK_REPO="https://github.com/matrix-org/matrix-js-sdk.git" \
|
||||
--build-arg JS_SDK_BRANCH="develop" \
|
||||
.
|
||||
```
|
||||
|
||||
## Kubernetes
|
||||
|
||||
The provided element-web docker image can also be run from within a Kubernetes cluster.
|
||||
See the [Kubernetes example](docs/kubernetes.md) for more details.
|
||||
37
docs/labs.md
37
docs/labs.md
|
|
@ -77,15 +77,6 @@ For some sample themes, check out [aaronraimist/element-themes](https://github.c
|
|||
Allows users to receive encrypted messages by creating a device that is stored
|
||||
encrypted on the server, as described in [MSC2697](https://github.com/matrix-org/matrix-doc/pull/2697).
|
||||
|
||||
## Right panel stays open (`feature_right_panel_default_open`)
|
||||
|
||||
This is an experimental default open right panel mode as a quick fix for those
|
||||
who prefer to have the right panel open consistently across rooms.
|
||||
|
||||
If no right panel state is known for the room or it was closed on the last room
|
||||
visit, it will default to the room member list. Otherwise, the saved card last
|
||||
used in that room is shown.
|
||||
|
||||
## Live location sharing (`feature_location_share_live`) [In Development]
|
||||
|
||||
Enables sharing your current location to the timeline, with live updates.
|
||||
|
|
@ -106,17 +97,33 @@ This feature allows users to place and join native [MSC3401](https://github.com/
|
|||
|
||||
If you're enabling this at the deployment level, you may also want to reference the docs for the `element_call` config section.
|
||||
|
||||
## Disable per-sender encryption for Element Call (`feature_disable_call_per_sender_encryption`)
|
||||
|
||||
The default for embedded Element Call in Element Web is per-participant encryption.
|
||||
This labs flag disables encryption for embedded Element Call in encrypted rooms.
|
||||
|
||||
Under the hood this stops Element Web from adding the `perParticipantE2EE` flag for the Element Call widget url.
|
||||
|
||||
This is useful while we experiment with encryption and to make calling compatible with platforms that don't use encryption yet.
|
||||
|
||||
## Rich text in room topics (`feature_html_topic`) [In Development]
|
||||
|
||||
Enables rendering of MD / HTML in room topics.
|
||||
|
||||
## Exploring public spaces (`feature_exploring_public_spaces`)
|
||||
|
||||
Enables exploring public spaces in the new search dialog. Requires the server to
|
||||
have [MSC3827](https://github.com/matrix-org/matrix-spec-proposals/pull/3827) enabled.
|
||||
|
||||
## Use the Rust cryptography implementation (`feature_rust_crypto`) [In Development]
|
||||
|
||||
Configures Element to use a new cryptography implementation based on the [matrix-rust-sdk](https://github.com/matrix-org/matrix-rust-sdk).
|
||||
|
||||
This setting is (currently) _sticky_ to a user's session: it only takes effect when the user logs in to a new session. Likewise, even after disabling the setting in `config.json`, the Rust implemention will remain in use until users log out.
|
||||
This setting is (currently) _sticky_ to a user's session: it only takes effect when the user logs in to a new session. Likewise, even after disabling the setting in `config.json`, the Rust implementation will remain in use until users log out.
|
||||
|
||||
## New room header & details (`feature_new_room_decoration_ui`) [In Development]
|
||||
|
||||
Refactors visually the room header and room sidebar
|
||||
|
||||
## Enable the notifications panel in the room header (`feature_notifications`)
|
||||
|
||||
Unreliable in encrypted rooms.
|
||||
|
||||
## Knock rooms (`feature_ask_to_join`) [In Development]
|
||||
|
||||
Enables knock feature for rooms. This allows users to ask to join a room.
|
||||
|
|
|
|||
14
docs/lib/custom.css
Normal file
14
docs/lib/custom.css
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
/* Prevent collapsible headings from wrapping onto two lines eagerly */
|
||||
summary > h1,
|
||||
summary > h2,
|
||||
summary > h3,
|
||||
summary > h4,
|
||||
summary > h5,
|
||||
summary > h6 {
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
/* Prevent longer checkbox lists from wrapping eagerly */
|
||||
input + p {
|
||||
display: inline;
|
||||
}
|
||||
1
docs/lib/mermaid-init.js
Normal file
1
docs/lib/mermaid-init.js
Normal file
|
|
@ -0,0 +1 @@
|
|||
mermaid.initialize({ startOnLoad:true });
|
||||
1648
docs/lib/mermaid.min.js
vendored
Normal file
1648
docs/lib/mermaid.min.js
vendored
Normal file
File diff suppressed because one or more lines are too long
43
docs/oidc.md
Normal file
43
docs/oidc.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# OIDC and delegated authentication
|
||||
|
||||
## Compatibility/OIDC-aware mode
|
||||
|
||||
[MSC2965: OIDC provider discovery](https://github.com/matrix-org/matrix-spec-proposals/pull/2965)
|
||||
[MSC3824: OIDC aware clients](https://github.com/matrix-org/matrix-spec-proposals/pull/3824)
|
||||
This mode uses an SSO flow to gain a `loginToken` from the authentication provider, then continues with SSO login.
|
||||
Element Web uses [MSC2965: OIDC provider discovery](https://github.com/matrix-org/matrix-spec-proposals/pull/2965) to discover the configured provider.
|
||||
Wherever valid MSC2965 configuration is discovered, OIDC-aware login flow will be the only option offered.
|
||||
|
||||
## (🧪Experimental) OIDC-native flow
|
||||
|
||||
Can be enabled by a config-level-only setting in `config.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"features": {
|
||||
"feature_oidc_native_flow": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
See https://areweoidcyet.com/client-implementation-guide/ for implementation details.
|
||||
|
||||
Element Web uses [MSC2965: OIDC provider discovery](https://github.com/matrix-org/matrix-spec-proposals/pull/2965) to discover the configured provider.
|
||||
Where OIDC native login flow is enabled and valid MSC2965 configuration is discovered, OIDC native login flow will be the only login option offered.
|
||||
Element Web will attempt to [dynamically register](https://openid.net/specs/openid-connect-registration-1_0.html) with the configured OP.
|
||||
Then, authentication will be completed [as described here](https://areweoidcyet.com/client-implementation-guide/).
|
||||
|
||||
#### Statically configured OIDC clients
|
||||
|
||||
Clients that are already registered with the OP can configure their `client_id` in `config.json`.
|
||||
Where static configuration exists for the OP dynamic client registration will not be attempted.
|
||||
|
||||
```json
|
||||
{
|
||||
"oidc_static_clients": {
|
||||
"https://dummyoidcprovider.com/": {
|
||||
"client_id": "abc123"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
268
docs/release.md
Normal file
268
docs/release.md
Normal file
|
|
@ -0,0 +1,268 @@
|
|||
> Tip: Paste this into the browser console to make the checkboxes on this page tickable. (Bear in mind that your ticks will be lost if you reload though.)
|
||||
>
|
||||
> ```
|
||||
> document.querySelectorAll("input[type='checkbox']").forEach(i => {i.disabled = false;})
|
||||
> ```
|
||||
|
||||
<details><summary><h1>Branches</h1></summary><blockquote>
|
||||
|
||||
#### develop
|
||||
|
||||
The develop branch holds the very latest and greatest code we have to offer, as such it may be less stable. It corresponds to the develop.element.io CD platform.
|
||||
|
||||
#### staging
|
||||
|
||||
The staging branch corresponds to the very latest release regardless of whether it is an RC or not. Deployed to staging.element.io manually.
|
||||
|
||||
#### master
|
||||
|
||||
The master branch is the most stable as it is the very latest non-RC release. Deployed to app.element.io manually.
|
||||
|
||||
</blockquote></details>
|
||||
|
||||
<details><summary><h1>Versions</h1></summary><blockquote>
|
||||
|
||||
The matrix-js-sdk follows semver, the matrix-react-sdk loosely follows semver, most releases for both will bump the minor version number.
|
||||
Breaking changes will bump the major version number.
|
||||
Element Web & Element Desktop do not follow semver and always have matching version numbers. The patch version number is normally incremented for every release.
|
||||
|
||||
</blockquote></details>
|
||||
|
||||
<details><summary><h1>Release Types</h1></summary><blockquote>
|
||||
|
||||
#### Release candidate
|
||||
|
||||
A normal release begins with a Release Candidate on the Tick phase of the release cycle,
|
||||
and may contain as many further RCs as are needed before the Tock phase of cycle.
|
||||
Each subsequent RC may add additional commits via any of the means of preparation.
|
||||
|
||||
A normal release is the most typical run-of-the-mill release,
|
||||
with at least one RC (Release Candidate) followed by a FINAL release.
|
||||
The typical cadence for these is every 2 weeks we'll do a new initial RC,
|
||||
then the following week we'll do that release cycle's FINAL release with sometimes more RCs in between, as needed.
|
||||
|
||||
#### Final
|
||||
|
||||
A normal release culminates with a Final release on the Tock phase of the cycle.
|
||||
This may be merely shipping the very latest RC with an adjusted version number,
|
||||
but can also include (hopefully small) additional changes present on `staging` if they are deemed safe to skip an RC.
|
||||
|
||||
### Hotfix / Security
|
||||
|
||||
This is an accelerated type of release which sits somewhere between RC and Final.
|
||||
They tend to contain few patches delta from the previous release but also skip any form of RC
|
||||
and in the case of Security the patch lands on GitHub only moments prior.
|
||||
For all intents and purposes they are the same as a Final release but with a different purpose.
|
||||
|
||||
</blockquote></details>
|
||||
|
||||
<details><summary><h1>Release Blockers</h1></summary><blockquote>
|
||||
|
||||
You should become release rabbit on the day after the last full release.
|
||||
For that week, it's your job to keep an eye on the Releases room and see whether any issues marked `X-Release-Blocker` are opened,
|
||||
or were already open. You should chase people to fix them, so that on RC day you can make the release.
|
||||
|
||||
If release-blocking issues are still open, you need to delay the release until they are fixed or reclassified.
|
||||
|
||||
There are two labels for tracking release blockers.
|
||||
|
||||
#### X-Release-Blocker
|
||||
|
||||
This label applied to an issue means we cannot ship a release affected by the specific issue.
|
||||
This means we cannot cut branches for an RC but security & hotfix releases may still be fine.
|
||||
|
||||
#### X-Upcoming-Release-Blocker
|
||||
|
||||
This label applied to an issue means that the next (read: not current) release cycle will be affected by the specific issue.
|
||||
This label will automagically convert to `X-Release-Blocker` at the conclusion of a full release.
|
||||
|
||||
</blockquote></details>
|
||||
|
||||
<details><summary><h1>Repositories</h1></summary><blockquote>
|
||||
|
||||
This release process revolves around our four main repositories:
|
||||
|
||||
- [Element Desktop](https://github.com/vector-im/element-desktop/)
|
||||
- [Element Web](https://github.com/vector-im/element-web/)
|
||||
- [Matrix React SDK](https://github.com/matrix-org/matrix-react-sdk/)
|
||||
- [Matrix JS SDK](https://github.com/matrix-org/matrix-js-sdk/)
|
||||
|
||||
We own other repositories, but they have more ad-hoc releases and are not part of the bi-weekly cycle:
|
||||
|
||||
- https://github.com/matrix-org/matrix-web-i18n/
|
||||
- https://github.com/matrix-org/matrix-react-sdk-module-api
|
||||
|
||||
</blockquote></details>
|
||||
|
||||
<details><summary><h1>Prerequisites</h1></summary><blockquote>
|
||||
|
||||
- You must be part of the 2 Releasers GitHub groups:
|
||||
- <https://github.com/orgs/vector-im/teams/element-web-releasers>
|
||||
- <https://github.com/orgs/matrix-org/teams/element-web-releasers>
|
||||
- You will need access to the **VPN** ([docs](https://gitlab.matrix.org/new-vector/internal/-/wikis/SRE/Tailscale)) to be able to follow the instructions under Deploy below.
|
||||
- You will need the ability to **SSH** in to the production machines to be able to follow the instructions under Deploy below. Ensure that your SSH key has a non-empty passphrase, and you registered your SSH key with Ops. Log a ticket at https://github.com/matrix-org/matrix-ansible-private and ask for:
|
||||
- Two-factor authentication to be set up on your SSH key. (This is needed to get access to production).
|
||||
- SSH access to `horme` (staging.element.io and app.element.io)
|
||||
- Permission to sudo on horme as the user `element`
|
||||
- You need "**jumphost**" configuration in your local `~/.ssh/config`. This should have been set up as part of your onboarding.
|
||||
|
||||
</blockquote></details>
|
||||
|
||||
<details><summary><h1>Overview</h1></summary><blockquote>
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
P[[Prepare staging branches]]
|
||||
P --> R1
|
||||
|
||||
subgraph Releasing
|
||||
R1[[Releasing matrix-js-sdk]]
|
||||
R2[[Releasing matrix-react-sdk]]
|
||||
R3[[Releasing element-web]]
|
||||
R4[[Releasing element-desktop]]
|
||||
|
||||
R1 --> R2 --> R3 --> R4
|
||||
end
|
||||
|
||||
R4 --> D1
|
||||
|
||||
subgraph Deploying
|
||||
D1[\Deploy staging.element.io/]
|
||||
D2[\Check dockerhub/]
|
||||
D3[\Deploy app.element.io/]
|
||||
D4[\Check desktop package/]
|
||||
|
||||
D1 --> D2 --> D
|
||||
D{FINAL?}
|
||||
D -->|Yes| D3 --> D4
|
||||
end
|
||||
|
||||
D -->|No| H1
|
||||
D4 --> H1
|
||||
|
||||
subgraph Housekeeping
|
||||
H1[\Update topics/]
|
||||
H2[\Announce/]
|
||||
H3[\Archive done column/]
|
||||
H4[\Add diary entry/]
|
||||
H5[\Renovate/]
|
||||
|
||||
H1 --> H2 --> H
|
||||
|
||||
H{FINAL?}
|
||||
H -->|Yes| H3 --> H4 --> DONE
|
||||
H -->|No| H5
|
||||
end
|
||||
|
||||
DONE([You are done!])
|
||||
H5 --> DONE
|
||||
```
|
||||
|
||||
</blockquote></details>
|
||||
|
||||
---
|
||||
|
||||
# Preparation
|
||||
|
||||
The goal of this stage is to get the code you want to ship onto the `staging` branch.
|
||||
There are multiple ways to accomplish this depending on the type of release you need to perform.
|
||||
|
||||
For the first RC in a given release cycle the easiest way to prepare branches is using the
|
||||
[Cut branches automation](https://github.com/vector-im/element-web/actions/workflows/release_prepare.yml) -
|
||||
this will take `develop` and merge it into the `staging` on the chosen repositories.
|
||||
|
||||
For subsequent RCs, if you need to include a change you may PR it directly to the `staging` branch or rely on the
|
||||
backport automation via labelling a PR to `develop` with `backport staging` which will cause a new PR to be opened
|
||||
which backports the requested change to the `staging` branch.
|
||||
|
||||
For security, you may wish to merge the security advisory private fork or apply the patches manually and then push them directly to `staging`.
|
||||
It is worth noting that at the end of the Final/Hotfix/Security release `staging` is merged to `master` which is merged back into `develop` -
|
||||
this means that any commit which goes to `staging` will eventually make its way back to the default branch.
|
||||
|
||||
- [ ] The staging branch is prepared
|
||||
|
||||
# Releasing
|
||||
|
||||
Shortly after concluding the preparation stage (or pushing any changes to `staging` in general);
|
||||
a draft release will be automatically made on the 4 project repositories with suggested changelogs and version numbers.
|
||||
|
||||
Review the draft releases created, check the version number makes sense and that the changelog contains everything you'd expect to.
|
||||
|
||||
_Note: we should add a step here to write summaries atop the changelogs manually, or via AI_
|
||||
|
||||
### Matrix JS SDK
|
||||
|
||||
The first stop is the matrix-js-sdk; kick off a release using [the automation](https://github.com/matrix-org/matrix-js-sdk/actions/workflows/release.yml) - making sure to select the right type of release. For anything other than an RC: choose final. You should not need to ever switch off either of the Publishing options.
|
||||
|
||||
- [ ] matrix-js-sdk has been released & published to npm
|
||||
|
||||
### Matrix React SDK
|
||||
|
||||
The next stop is matrix-react-sdk; kick off a release using [the automation](https://github.com/matrix-org/matrix-react-sdk/actions/workflows/release.yml) - making sure to select the right type of release. For anything other than an RC: choose final. In the JS SDK version field enter the version of the JS SDK you wish to use, for typical releases including all the layers this would be the version released in the stage above.
|
||||
|
||||
- [ ] matrix-react-sdk has been released & published to npm
|
||||
|
||||
### Element Web
|
||||
|
||||
The next stop is element-web; kick off a release using [the automation](https://github.com/vector-im/element-web/actions/workflows/release.yml) - making sure to select the right type of release. For anything other than an RC: choose final. In the SDK version fields enter the versions you wish to use, for typical releases including all the layers this would be the versions released in the stages above.
|
||||
|
||||
- [ ] Element Web has been released
|
||||
|
||||
### Element Desktop
|
||||
|
||||
The next stop is element-desktop; kick off a release using [the automation](https://github.com/vector-im/element-desktop/actions/workflows/release.yml) - making sure to select the right type of release. For anything other than an RC: choose final. In the JS SDK version field enter the version of the JS SDK you wish to use, for typical releases including all the layers this would be the version released in the stage above.
|
||||
|
||||
- [ ] Element Desktop has been released
|
||||
|
||||
# Deploying
|
||||
|
||||
We ship the SDKs to npm, this happens as part of the release process.
|
||||
We ship Element Web to dockerhub, `*.element.io`, and packages.element.io.
|
||||
We ship Element Desktop to packages.element.io.
|
||||
|
||||
- [ ] Check that element-web has shipped to dockerhub
|
||||
- [ ] Deploy staging.element.io. [See docs.](https://handbook.element.io/books/element-web-team/page/deploying-appstagingelementio)
|
||||
- [ ] Test staging.element.io
|
||||
|
||||
For final releases additionally do these steps:
|
||||
|
||||
- [ ] Deploy app.element.io. [See docs.](https://handbook.element.io/books/element-web-team/page/deploying-appstagingelementio)
|
||||
- [ ] Test app.element.io
|
||||
- [ ] Ensure Element Web package has shipped to packages.element.io
|
||||
- [ ] Ensure Element Desktop packages have shipped to packages.element.io
|
||||
|
||||
# Housekeeping
|
||||
|
||||
We have some manual housekeeping to do in order to prepare for the next release.
|
||||
|
||||
- [ ] Update topics using [the automation](https://github.com/vector-im/element-web/actions/workflows/update-topics.yaml). It will autodetect the current latest version. Don't forget the date you supply should be e.g. September 5th (including the "th") for the script to work.
|
||||
- [ ] Announce the release in [#element-web-announcements:matrix.org](https://matrix.to/#/#element-web-announcements:matrix.org)
|
||||
|
||||
<details><summary>(show)</summary>
|
||||
|
||||
With wording like:
|
||||
|
||||
> Element Web v1.11.24 is here!
|
||||
>
|
||||
> This version adds ... and fixes bugs ...
|
||||
>
|
||||
> Check it out at app.element.io, in Element Desktop, or from Docker Hub. Changelog and more details at https://github.com/vector-im/element-web/releases/tag/v1.11.24
|
||||
|
||||
</details>
|
||||
|
||||
For the first RC of a given release cycle do these steps:
|
||||
|
||||
- [ ] Go to the [matrix-js-sdk Renovate dashboard](https://github.com/matrix-org/matrix-js-sdk/issues/2406) and click the checkbox to create/update its PRs.
|
||||
|
||||
- [ ] Go to the [matrix-react-sdk Renovate dashboard](https://github.com/matrix-org/matrix-react-sdk/issues/9667) and click the checkbox to create/update its PRs.
|
||||
|
||||
- [ ] Go to the [element-web Renovate dashboard](https://github.com/vector-im/element-web/issues/22941) and click the checkbox to create/update its PRs.
|
||||
|
||||
- [ ] Go to the [element-desktop Renovate dashboard](https://github.com/vector-im/element-desktop/issues/465) and click the checkbox to create/update its PRs.
|
||||
|
||||
- [ ] Later, check back and merge the PRs that succeeded to build. The ones that failed will get picked up by the [maintainer](https://docs.google.com/document/d/1V5VINWXATMpz9UBw4IKmVVB8aw3CxM0Jt7igtHnDfSk/edit#).
|
||||
|
||||
For final releases additionally do these steps:
|
||||
|
||||
- [ ] Archive done column on the [team board](https://github.com/orgs/vector-im/projects/67/views/34) _Note: this should be automated_
|
||||
- [ ] Add entry to the [milestones diary](https://docs.google.com/document/d/1cpRFJdfNCo2Ps6jqzQmatzbYEToSrQpyBug0aP_iwZE/edit#heading=h.6y55fw4t283z). The document says only to add significant releases, but we add all of them just in case.
|
||||
|
|
@ -6,11 +6,16 @@
|
|||
- Including up-to-date versions of matrix-react-sdk and matrix-js-sdk
|
||||
- Latest LTS version of Node.js installed
|
||||
- Be able to understand English
|
||||
- Be able to understand the language you want to translate Element into
|
||||
|
||||
## Translating strings vs. marking strings for translation
|
||||
|
||||
Translating strings are done with the `_t()` function found in matrix-react-sdk/lib/languageHandler.js. It is recommended to call this function wherever you introduce a string constant which should be translated. However, translating can not be performed until after the translation system has been initialized. Thus, sometimes translation must be performed at a different location in the source code than where the string is introduced. This breaks some tooling and makes it difficult to find translatable strings. Therefore, there is the alternative `_td()` function which is used to mark strings for translation, without actually performing the translation (which must still be performed separately, and after the translation system has been initialized).
|
||||
Translating strings are done with the `_t()` function found in matrix-react-sdk/lib/languageHandler.js.
|
||||
It is recommended to call this function wherever you introduce a string constant which should be translated.
|
||||
However, translating can not be performed until after the translation system has been initialized.
|
||||
Thus, sometimes translation must be performed at a different location in the source code than where the string is introduced.
|
||||
This breaks some tooling and makes it difficult to find translatable strings.
|
||||
Therefore, there is the alternative `_td()` function which is used to mark strings for translation,
|
||||
without actually performing the translation (which must still be performed separately, and after the translation system has been initialized).
|
||||
|
||||
Basically, whenever a translatable string is introduced, you should call either `_t()` immediately OR `_td()` and later `_t()`.
|
||||
|
||||
|
|
@ -29,27 +34,39 @@ function getColorName(hex) {
|
|||
}
|
||||
```
|
||||
|
||||
## Key naming rules
|
||||
|
||||
These rules are based on https://github.com/vector-im/element-x-android/blob/develop/tools/localazy/README.md
|
||||
At this time we are not trying to have a translation key per UI element as some methodologies use,
|
||||
whilst that would offer the greatest flexibility, it would also make reuse between projects nigh impossible.
|
||||
We are aiming for a set of common strings to be shared then some more localised translations per context they may appear in.
|
||||
|
||||
1. Ensure the string doesn't already exist in a related project, such as https://localazy.com/p/element
|
||||
2. Keys for common strings, i.e. strings that can be used at multiple places must start by `action_` if this is a verb, or `common_` if not
|
||||
3. Keys for common accessibility strings must start by `a11y_`. Example: `a11y_hide_password`
|
||||
4. Otherwise, try to group keys logically and nest where appropriate, such as `keyboard_` for strings relating to keyboard shortcuts.
|
||||
5. Ensure your translation keys do not include `.` or `|` or ` `. Try to balance string length against descriptiveness.
|
||||
|
||||
## Adding new strings
|
||||
|
||||
1. Check if the import `import { _t } from 'matrix-react-sdk/src/languageHandler';` is present. If not add it to the other import statements. Also import `_td` if needed.
|
||||
1. Add `_t()` to your string. (Don't forget curly braces when you assign an expression to JSX attributes in the render method). If the string is introduced at a point before the translation system has not yet been initialized, use `_td()` instead, and call `_t()` at the appropriate time.
|
||||
1. Run `yarn i18n` to update `src/i18n/strings/en_EN.json`
|
||||
1. If you added a string with a plural, you can add other English plural variants to `src/i18n/strings/en_EN.json` (remeber to edit the one in the same project as the source file containing your new translation).
|
||||
1. Check if the import `import { _t } from 'matrix-react-sdk/src/languageHandler';` is present. If not add it to the other import statements. Also import `_td` if needed.
|
||||
1. Add `_t()` to your string passing the translation key you come up with based on the rules above. If the string is introduced at a point before the translation system has not yet been initialized, use `_td()` instead, and call `_t()` at the appropriate time.
|
||||
1. Run `yarn i18n` to add the keys to `src/i18n/strings/en_EN.json`
|
||||
1. Modify the new entries in `src/i18n/strings/en_EN.json` with the English (UK) translations for the added keys.
|
||||
|
||||
## Editing existing strings
|
||||
|
||||
1. Edit every occurrence of the string inside `_t()` and `_td()` in the JSX files.
|
||||
1. Run `yarn i18n` to update `src/i18n/strings/en_EN.json`. (Be sure to run this in the same project as the JSX files you just edited.)
|
||||
1. Run `yarn prunei18n` to remove the old string from `src/i18n/strings/*.json`.
|
||||
Edits to existing strings should be performed only via Localazy.
|
||||
There you can also require all translations to be redone if the meaning of the string has changed significantly.
|
||||
|
||||
## Adding variables inside a string.
|
||||
|
||||
1. Extend your `_t()` call. Instead of `_t(STRING)` use `_t(STRING, {})`
|
||||
1. Extend your `_t()` call. Instead of `_t(TKEY)` use `_t(TKEY, {})`
|
||||
1. Decide how to name it. Please think about if the person who has to translate it can understand what it does. E.g. using the name 'recipient' is bad, because a translator does not know if it is the name of a person, an email address, a user ID, etc. Rather use e.g. recipientEmailAddress.
|
||||
1. Add it to the array in `_t` for example `_t(STRING, {variable: this.variable})`
|
||||
1. Add it to the array in `_t` for example `_t(TKEY, {variable: this.variable})`
|
||||
1. Add the variable inside the string. The syntax for variables is `%(variable)s`. Please note the _s_ at the end. The name of the variable has to match the previous used name.
|
||||
|
||||
- You can use the special `count` variable to choose between multiple versions of the same string, in order to get the correct pluralization. E.g. `_t('You have %(count)s new messages', { count: 2 })` would show 'You have 2 new messages', while `_t('You have %(count)s new messages', { count: 1 })` would show 'You have one new message' (assuming a singular version of the string has been added to the translation file. See above). Passing in `count` is much prefered over having an if-statement choose the correct string to use, because some languages have much more complicated plural rules than english (e.g. they might need a completely different form if there are three things rather than two).
|
||||
- You can use the special `count` variable to choose between multiple versions of the same string, in order to get the correct pluralization. E.g. `_t('You have %(count)s new messages', { count: 2 })` would show 'You have 2 new messages', while `_t('You have %(count)s new messages', { count: 1 })` would show 'You have one new message' (assuming a singular version of the string has been added to the translation file. See above). Passing in `count` is much preferred over having an if-statement choose the correct string to use, because some languages have much more complicated plural rules than english (e.g. they might need a completely different form if there are three things rather than two).
|
||||
- If you want to translate text that includes e.g. hyperlinks or other HTML you have to also use tag substitution, e.g. `_t('<a>Click here!</a>', {}, { 'a': (sub) => <a>{sub}</a> })`. If you don't do the tag substitution you will end up showing literally '<a>' rather than making a hyperlink.
|
||||
- You can also use React components with normal variable substitution if you want to insert HTML markup, e.g. `_t('Your email address is %(emailAddress)s', { emailAddress: <i>{userEmailAddress}</i> })`.
|
||||
|
||||
|
|
@ -61,4 +78,5 @@ function getColorName(hex) {
|
|||
- Avoid "translation in parts", i.e. concatenating translated strings or using translated strings in variable substitutions. Context is important for translations, and translating partial strings this way is simply not always possible.
|
||||
- Concatenating strings often also introduces an implicit assumption about word order (e.g. that the subject of the sentence comes first), which is incorrect for many languages.
|
||||
- Translation 'smell test': If you have a string that does not begin with a capital letter (is not the start of a sentence) or it ends with e.g. ':' or a preposition (e.g. 'to') you should recheck that you are not trying to translate a partial sentence.
|
||||
- If you have multiple strings, that are almost identical, except some part (e.g. a word or two) it is still better to translate the full sentence multiple times. It may seem like inefficient repetion, but unlike programming where you try to minimize repetition, translation is much faster if you have many, full, clear, sentences to work with, rather than fewer, but incomplete sentence fragments.
|
||||
- If you have multiple strings, that are almost identical, except some part (e.g. a word or two) it is still better to translate the full sentence multiple times. It may seem like inefficient repetition, but unlike programming where you try to minimize repetition, translation is much faster if you have many, full, clear, sentences to work with, rather than fewer, but incomplete sentence fragments.
|
||||
- Don't forget curly braces when you assign an expression to JSX attributes in the render method)
|
||||
|
|
|
|||
|
|
@ -6,58 +6,31 @@
|
|||
- Be able to understand English
|
||||
- Be able to understand the language you want to translate Element into
|
||||
|
||||
## Step 0: Join #element-translations:matrix.org
|
||||
## Join #element-translations:matrix.org
|
||||
|
||||
1. Come and join https://matrix.to/#/#element-translations:matrix.org for general discussion
|
||||
2. Join https://matrix.to/#/#element-translators:matrix.org for language-specific rooms
|
||||
3. Read scrollback and/or ask if anyone else is working on your language, and co-ordinate if needed. In general little-or-no coordination is needed though :)
|
||||
|
||||
## Step 1: Preparing your Weblate Profile
|
||||
|
||||
1. Head to https://translate.element.io and register either via Github or email
|
||||
2. After registering check if you got an email to verify your account and click the link (if there is none head to step 1.4)
|
||||
3. Log into weblate
|
||||
4. Head to https://translate.element.io/accounts/profile/ and select the languages you know and maybe another language you know too.
|
||||
|
||||
## How to check if your language already is being translated
|
||||
|
||||
Go to https://translate.element.io/projects/element-web/ and visit the 2 sub-projects.
|
||||
If your language is listed go to Step 2a and if not go to Step 2b
|
||||
Go to https://localazy.com/p/element-web
|
||||
If your language is listed then you can get started, have a read of https://localazy.com/docs/general/translating-strings
|
||||
if you need help getting started. If your language is not yet listed please express your wishes to start translating it in
|
||||
the general discussion room linked above.
|
||||
|
||||
## Step 2a: Helping on existing languages.
|
||||
### What are `%(something)s`?
|
||||
|
||||
1. Head to one of the projects listed https://translate.element.io/projects/element-web/
|
||||
2. Click on the `translate` button on the right side of your language
|
||||
3. Fill in the translations in the writeable field. You will see the original English string and the string of your second language above.
|
||||
These things are placeholders that are expanded when displayed by Element. They can be room names, usernames or similar.
|
||||
If you find one, you can move to the right place for your language, but not delete it as the variable will be missing if you do.
|
||||
A special case is `%(count)s` as this is also used to determine which pluralisation is used.
|
||||
|
||||
Head to the explanations under Steb 2b
|
||||
### What are `<link>Something</link>`
|
||||
|
||||
## Step 2b: Adding a new language
|
||||
These things are markup tags, they encapsulate sections of translations to be marked up, with links, buttons, emphasis and such.
|
||||
You must keep these markers surrounding the equivalent string in your language that needs to be marked up.
|
||||
|
||||
1. Go to one of the projects listed https://translate.element.io/projects/element-web/
|
||||
2. Click the `Start new translation` button at the bottom
|
||||
3. Select a language
|
||||
4. Start translating like in 2a.3
|
||||
5. Repeat these steps for the other projects which are listed at the link of step 2b.1
|
||||
### When will my translations be available?
|
||||
|
||||
### What means the green button under the text field?
|
||||
|
||||
The green button let you save our translations directly. Please only use it if you are 100% sure about that translation. If you do not know a translation please DO NOT click that button. Use the arrows above the translations field and click to the right.
|
||||
|
||||
### What means the yellow button under the text field?
|
||||
|
||||
The yellow button has to be used if you are unsure about the translation but you have a rough idea. It adds a new suggestion to the string which can than be reviewed by others.
|
||||
|
||||
### What are "%(something)s"?
|
||||
|
||||
These things are variables that are expanded when displayed by Element. They can be room names, usernames or similar. If you find one, you can move to the right place for your language, but not delete it as the variable will be missing if you do.
|
||||
|
||||
A special case is `%(urlStart)s` and `%(urlEnd)s` which are used to mark the beginning of a hyperlink (i.e. `<a href="/somewhere">` and `</a>`. You must keep these markers surrounding the equivalent string in your language that needs to be hyperlinked.
|
||||
|
||||
### "I want to come back to this string. How?"
|
||||
|
||||
You can use inside the translation field "Review needed" checkbox. It will be shown as Strings that need to be reviewed.
|
||||
|
||||
### Further reading
|
||||
|
||||
The official Weblate doc provides some more in-depth explanation on how to do translations and talks about do and don'ts. You can find it at: https://docs.weblate.org/en/latest/user/translating.html
|
||||
We automatically pull changes from Localazy 3 times a week, so your translations should be available at https://develop.element.io
|
||||
within a few days of you submitting them and them being approved. They will then also be included in the following release cycle.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue