Apply prettier formatting
This commit is contained in:
Michael Weimann
parent
a32f12c8f3
commit
7921a6cbf8
104 changed files with 12169 additions and 11047 deletions
|
|
@ -15,10 +15,10 @@ Current more parallel flow:
|
|||
digraph G {
|
||||
node [shape=box];
|
||||
|
||||
subgraph cluster_0 {
|
||||
color=orange;
|
||||
node [style=filled];
|
||||
label = "index.ts";
|
||||
subgraph cluster_0 {
|
||||
color=orange;
|
||||
node [style=filled];
|
||||
label = "index.ts";
|
||||
|
||||
entrypoint, s0, ready [shape=point];
|
||||
rageshake, config, i18n, theme, skin, olm [shape=parallelogram];
|
||||
|
|
@ -52,33 +52,38 @@ digraph G {
|
|||
skin -> ready [color=red];
|
||||
theme -> ready [color=red];
|
||||
i18n -> ready [color=red];
|
||||
}
|
||||
|
||||
subgraph cluster_1 {
|
||||
color = green;
|
||||
node [style=filled];
|
||||
label = "init.tsx";
|
||||
}
|
||||
|
||||
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
|
||||
+ Blue arrow: async task is allowed to settle but allowed to fail
|
||||
+ Red arrow: async task success is asserted
|
||||
|
||||
- Parallelogram: async/await task
|
||||
- Box: sync task
|
||||
- Diamond: conditional branch
|
||||
- Egg: user interaction
|
||||
- Blue arrow: async task is allowed to settle but allowed to fail
|
||||
- Red arrow: async task success is asserted
|
||||
|
||||
Notes:
|
||||
+ A task begins when all its dependencies (arrows going into it) are fulfilled.
|
||||
+ The success of setting up rageshake is never asserted, element-web has a fallback path for running without IDB (and thus rageshake).
|
||||
+ Everything is awaited to be settled before the Modernizr check, to allow it to make use of things like i18n if they are successful.
|
||||
|
||||
- A task begins when all its dependencies (arrows going into it) are fulfilled.
|
||||
- The success of setting up rageshake is never asserted, element-web has a fallback path for running without IDB (and thus rageshake).
|
||||
- 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:
|
||||
|
||||
|
|
|
|||
|
|
@ -33,19 +33,19 @@ someone to add something.
|
|||
When you're looking through the list, here are some things that might make an
|
||||
issue a **GOOD** choice:
|
||||
|
||||
* It is a problem or feature you care about.
|
||||
* It concerns a type of code you know a little about.
|
||||
* You think you can understand what's needed.
|
||||
* It already has approval from Element Web's designers (look for comments from
|
||||
members of the
|
||||
[Product](https://github.com/orgs/vector-im/teams/product/members) or
|
||||
[Design](https://github.com/orgs/vector-im/teams/design/members) teams).
|
||||
- It is a problem or feature you care about.
|
||||
- It concerns a type of code you know a little about.
|
||||
- You think you can understand what's needed.
|
||||
- It already has approval from Element Web's designers (look for comments from
|
||||
members of the
|
||||
[Product](https://github.com/orgs/vector-im/teams/product/members) or
|
||||
[Design](https://github.com/orgs/vector-im/teams/design/members) teams).
|
||||
|
||||
Here are some things that might make it a **BAD** choice:
|
||||
|
||||
* You don't understand it (maybe add a comment asking a clarifying question).
|
||||
* It sounds difficult, or is part of a larger change you don't know about.
|
||||
* **It is tagged with `X-Needs-Design` or `X-Needs-Product`.**
|
||||
- You don't understand it (maybe add a comment asking a clarifying question).
|
||||
- It sounds difficult, or is part of a larger change you don't know about.
|
||||
- **It is tagged with `X-Needs-Design` or `X-Needs-Product`.**
|
||||
|
||||
**Element Web's Design and Product teams tend to be very busy**, so if you make
|
||||
changes that require approval from one of those teams, you will probably have
|
||||
|
|
|
|||
388
docs/config.md
388
docs/config.md
|
|
@ -17,7 +17,7 @@ for the desktop app the application will need to be exited fully (including via
|
|||
|
||||
## Homeserver configuration
|
||||
|
||||
In order for Element to even start you will need to tell it what homeserver to connect to *by default*. Users will be
|
||||
In order for Element to even start you will need to tell it what homeserver to connect to _by default_. Users will be
|
||||
able to use a different homeserver if they like, though this can be disabled with `"disable_custom_urls": true` in your
|
||||
config.
|
||||
|
||||
|
|
@ -26,18 +26,18 @@ One of the following options **must** be supplied:
|
|||
1. `default_server_config`: The preferred method of setting the homeserver connection information. Simply copy/paste
|
||||
your [`/.well-known/matrix/client`](https://spec.matrix.org/latest/client-server-api/#getwell-knownmatrixclient)
|
||||
into this field. For example:
|
||||
```json
|
||||
{
|
||||
"default_server_config": {
|
||||
"m.homeserver": {
|
||||
"base_url": "https://matrix-client.matrix.org"
|
||||
},
|
||||
"m.identity_server": {
|
||||
"base_url": "https://vector.im"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"default_server_config": {
|
||||
"m.homeserver": {
|
||||
"base_url": "https://matrix-client.matrix.org"
|
||||
},
|
||||
"m.identity_server": {
|
||||
"base_url": "https://vector.im"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
2. `default_server_name`: A different method of connecting to the homeserver by looking up the connection information
|
||||
using `.well-known`. When using this option, simply use your server's domain name (the part at the end of user IDs):
|
||||
`"default_server_name": "matrix.org"`
|
||||
|
|
@ -58,10 +58,10 @@ To force a labs flag on or off, use the following:
|
|||
|
||||
```json
|
||||
{
|
||||
"features": {
|
||||
"feature_you_want_to_turn_on": true,
|
||||
"feature_you_want_to_keep_off": false
|
||||
}
|
||||
"features": {
|
||||
"feature_you_want_to_turn_on": true,
|
||||
"feature_you_want_to_keep_off": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -82,25 +82,25 @@ instance. As of writing those settings are not fully documented, however a few a
|
|||
inputs.
|
||||
3. `room_directory`: Optionally defines how the room directory component behaves. Currently only a single property, `servers`
|
||||
is supported to add additional servers to the dropdown. For example:
|
||||
```json
|
||||
{
|
||||
"room_directory": {
|
||||
"servers": ["matrix.org", "example.org"]
|
||||
}
|
||||
}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"room_directory": {
|
||||
"servers": ["matrix.org", "example.org"]
|
||||
}
|
||||
}
|
||||
```
|
||||
4. `setting_defaults`: Optional configuration for settings which are not described by this document and support the `config`
|
||||
level. This list is incomplete. For example:
|
||||
```json
|
||||
{
|
||||
"setting_defaults": {
|
||||
"MessageComposerInput.showStickersButton": false,
|
||||
"MessageComposerInput.showPollsButton": false
|
||||
}
|
||||
}
|
||||
```
|
||||
These values will take priority over the hardcoded defaults for the settings. For a list of available settings, see
|
||||
[Settings.tsx](https://github.com/matrix-org/matrix-react-sdk/blob/develop/src/settings/Settings.tsx).
|
||||
```json
|
||||
{
|
||||
"setting_defaults": {
|
||||
"MessageComposerInput.showStickersButton": false,
|
||||
"MessageComposerInput.showPollsButton": false
|
||||
}
|
||||
}
|
||||
```
|
||||
These values will take priority over the hardcoded defaults for the settings. For a list of available settings, see
|
||||
[Settings.tsx](https://github.com/matrix-org/matrix-react-sdk/blob/develop/src/settings/Settings.tsx).
|
||||
|
||||
## Customisation & branding
|
||||
|
||||
|
|
@ -170,16 +170,16 @@ Together, these two options might look like the following in your config:
|
|||
|
||||
```json
|
||||
{
|
||||
"desktop_builds": {
|
||||
"available": true,
|
||||
"logo": "https://example.org/assets/logo-small.svg",
|
||||
"url": "https://example.org/not_element/download"
|
||||
},
|
||||
"mobile_builds": {
|
||||
"ios": null,
|
||||
"android": "https://example.org/not_element/android",
|
||||
"fdroid": "https://example.org/not_element/fdroid"
|
||||
}
|
||||
"desktop_builds": {
|
||||
"available": true,
|
||||
"logo": "https://example.org/assets/logo-small.svg",
|
||||
"url": "https://example.org/not_element/download"
|
||||
},
|
||||
"mobile_builds": {
|
||||
"ios": null,
|
||||
"android": "https://example.org/not_element/android",
|
||||
"fdroid": "https://example.org/not_element/fdroid"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -210,18 +210,18 @@ Together, the options might look like this in your config:
|
|||
|
||||
```json
|
||||
{
|
||||
"branding": {
|
||||
"welcome_background_url": "https://example.org/assets/background.jpg",
|
||||
"auth_header_logo_url": "https://example.org/assets/logo.svg",
|
||||
"auth_footer_links": [
|
||||
{"text": "FAQ", "url": "https://example.org/faq"},
|
||||
{"text": "Donate", "url": "https://example.org/donate"}
|
||||
]
|
||||
},
|
||||
"embedded_pages": {
|
||||
"welcome_url": "https://example.org/assets/welcome.html",
|
||||
"home_url": "https://example.org/assets/home.html"
|
||||
}
|
||||
"branding": {
|
||||
"welcome_background_url": "https://example.org/assets/background.jpg",
|
||||
"auth_header_logo_url": "https://example.org/assets/logo.svg",
|
||||
"auth_footer_links": [
|
||||
{ "text": "FAQ", "url": "https://example.org/faq" },
|
||||
{ "text": "Donate", "url": "https://example.org/donate" }
|
||||
]
|
||||
},
|
||||
"embedded_pages": {
|
||||
"welcome_url": "https://example.org/assets/welcome.html",
|
||||
"home_url": "https://example.org/assets/home.html"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -240,15 +240,15 @@ When Element is deployed alongside a homeserver with SSO-only login, some option
|
|||
2. `sso_redirect_options`: Options to define how to handle unauthenticated users. If the object contains `"immediate": true`, then
|
||||
all unauthenticated users will be automatically redirected to the SSO system to start their login. If instead you'd only like to
|
||||
have users which land on the welcome page to be redirected, use `"on_welcome_page": true`. As an example:
|
||||
```json
|
||||
{
|
||||
"sso_redirect_options": {
|
||||
"immediate": false,
|
||||
"on_welcome_page": true
|
||||
}
|
||||
}
|
||||
```
|
||||
It is most common to use the `immediate` flag instead of `on_welcome_page`.
|
||||
```json
|
||||
{
|
||||
"sso_redirect_options": {
|
||||
"immediate": false,
|
||||
"on_welcome_page": true
|
||||
}
|
||||
}
|
||||
```
|
||||
It is most common to use the `immediate` flag instead of `on_welcome_page`.
|
||||
|
||||
## VoIP / Jitsi calls
|
||||
|
||||
|
|
@ -261,77 +261,77 @@ More information about the Jitsi setup can be found [here](./jitsi.md).
|
|||
The VoIP and Jitsi options are:
|
||||
|
||||
1. `jitsi`: Optional configuration for how to start Jitsi conferences. Currently can only contain a single `preferred_domain`
|
||||
value which points at the domain of the Jitsi instance. Defaults to `meet.element.io`. This is *not* used if the Jitsi widget
|
||||
value which points at the domain of the Jitsi instance. Defaults to `meet.element.io`. This is _not_ used if the Jitsi widget
|
||||
was created by an integration manager, or if the homeserver provides Jitsi information in `/.well-known/matrix/client`. For
|
||||
example:
|
||||
```json
|
||||
{
|
||||
"jitsi": {
|
||||
"preferred_domain": "meet.jit.si"
|
||||
}
|
||||
}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"jitsi": {
|
||||
"preferred_domain": "meet.jit.si"
|
||||
}
|
||||
}
|
||||
```
|
||||
2. `jitsi_widget`: Optional configuration for the built-in Jitsi widget. Currently can only contain a single `skip_built_in_welcome_screen`
|
||||
value, denoting whether the "Join Conference" button should be shown. When `true` (default `false`), Jitsi calls will skip to
|
||||
the call instead of having a screen with a single button on it. This is most useful if the Jitsi instance being used already
|
||||
has a landing page for users to test audio and video before joining the call, otherwise users will automatically join the call.
|
||||
For example:
|
||||
```json
|
||||
{
|
||||
"jitsi_widget": {
|
||||
"skip_built_in_welcome_screen": true
|
||||
}
|
||||
}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"jitsi_widget": {
|
||||
"skip_built_in_welcome_screen": true
|
||||
}
|
||||
}
|
||||
```
|
||||
3. `voip`: Optional configuration for various VoIP features. Currently can only contain a single `obey_asserted_identity` value to
|
||||
send MSC3086-style asserted identity messages during VoIP calls in the room corresponding to the asserted identity. This *must*
|
||||
send MSC3086-style asserted identity messages during VoIP calls in the room corresponding to the asserted identity. This _must_
|
||||
only be set in trusted environments. The option defaults to `false`. For example:
|
||||
```json
|
||||
{
|
||||
"voip": {
|
||||
"obey_asserted_identity": false
|
||||
}
|
||||
}
|
||||
```
|
||||
```json
|
||||
{
|
||||
"voip": {
|
||||
"obey_asserted_identity": false
|
||||
}
|
||||
}
|
||||
```
|
||||
4. `widget_build_url`: Optional URL to have Element make a request to when a user presses the voice/video call buttons in the app,
|
||||
if a call would normally be started by the action. The URL will be called with a `roomId` query parameter to identify the room
|
||||
being called in. The URL must respond with a JSON object similar to the following:
|
||||
```json
|
||||
{
|
||||
"widget_id": "$arbitrary_string",
|
||||
"widget": {
|
||||
"creatorUserId": "@user:example.org",
|
||||
"id": "$the_same_widget_id",
|
||||
"type": "m.custom",
|
||||
"waitForIframeLoad": true,
|
||||
"name": "My Widget Name Here",
|
||||
"avatar_url": "mxc://example.org/abc123",
|
||||
"url": "https://example.org/widget.html",
|
||||
"data": {
|
||||
"title": "Subtitle goes here"
|
||||
}
|
||||
},
|
||||
"layout": {
|
||||
"container": "top",
|
||||
"index": 0,
|
||||
"width": 65,
|
||||
"height": 50
|
||||
}
|
||||
}
|
||||
```
|
||||
The `widget` is the `content` of a normal widget state event. The `layout` is the layout specifier for the widget being created,
|
||||
as defined by the `io.element.widgets.layout` state event.
|
||||
```json
|
||||
{
|
||||
"widget_id": "$arbitrary_string",
|
||||
"widget": {
|
||||
"creatorUserId": "@user:example.org",
|
||||
"id": "$the_same_widget_id",
|
||||
"type": "m.custom",
|
||||
"waitForIframeLoad": true,
|
||||
"name": "My Widget Name Here",
|
||||
"avatar_url": "mxc://example.org/abc123",
|
||||
"url": "https://example.org/widget.html",
|
||||
"data": {
|
||||
"title": "Subtitle goes here"
|
||||
}
|
||||
},
|
||||
"layout": {
|
||||
"container": "top",
|
||||
"index": 0,
|
||||
"width": 65,
|
||||
"height": 50
|
||||
}
|
||||
}
|
||||
```
|
||||
The `widget` is the `content` of a normal widget state event. The `layout` is the layout specifier for the widget being created,
|
||||
as defined by the `io.element.widgets.layout` state event.
|
||||
5. `audio_stream_url`: Optional URL to pass to Jitsi to enable live streaming. This option is considered experimental and may be removed
|
||||
at any time without notice.
|
||||
6. `element_call`: Optional configuration for native group calls using Element Call, with the following subkeys:
|
||||
- `url`: The URL of the Element Call instance to use for native group calls. This option is considered experimental
|
||||
- `url`: The URL of the Element Call instance to use for native group calls. This option is considered experimental
|
||||
and may be removed at any time without notice. Defaults to `https://call.element.io`.
|
||||
- `use_exclusively`: A boolean specifying whether Element Call should be used exclusively as the only VoIP stack in
|
||||
- `use_exclusively`: A boolean specifying whether Element Call should be used exclusively as the only VoIP stack in
|
||||
the app, removing the ability to start legacy 1:1 calls or Jitsi calls. Defaults to `false`.
|
||||
- `participant_limit`: The maximum number of users who can join a call; if
|
||||
this number is exceeded, the user will not be able to join a given call.
|
||||
- `brand`: Optional name for the app. Defaults to `Element Call`. This is
|
||||
used throughout the application in various strings/locations.
|
||||
- `participant_limit`: The maximum number of users who can join a call; if
|
||||
this number is exceeded, the user will not be able to join a given call.
|
||||
- `brand`: Optional name for the app. Defaults to `Element Call`. This is
|
||||
used throughout the application in various strings/locations.
|
||||
|
||||
## Bug reporting
|
||||
|
||||
|
|
@ -344,7 +344,7 @@ If you run your own rageshake server to collect bug reports, the following optio
|
|||
alongside the rageshake so the rageshake server can filter them by app name. By default, this will be `element-web`, as with any other
|
||||
rageshake submitted by the app.
|
||||
|
||||
If you are using the element.io rageshake server, please set this to `element-auto-uisi` so we can better filter them.
|
||||
If you are using the element.io rageshake server, please set this to `element-auto-uisi` so we can better filter them.
|
||||
|
||||
If you would like to use [Sentry](https://sentry.io/) for rageshake data, add a `sentry` object to your config with the following values:
|
||||
|
||||
|
|
@ -355,10 +355,10 @@ For example:
|
|||
|
||||
```json
|
||||
{
|
||||
"sentry": {
|
||||
"dsn": "dsn-goes-here",
|
||||
"environment": "production"
|
||||
}
|
||||
"sentry": {
|
||||
"dsn": "dsn-goes-here",
|
||||
"environment": "production"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -375,15 +375,15 @@ If you would like to use Scalar, the integration manager maintained by Element,
|
|||
|
||||
```json
|
||||
{
|
||||
"integrations_ui_url": "https://scalar.vector.im/",
|
||||
"integrations_rest_url": "https://scalar.vector.im/api",
|
||||
"integrations_widgets_urls": [
|
||||
"https://scalar.vector.im/_matrix/integrations/v1",
|
||||
"https://scalar.vector.im/api",
|
||||
"https://scalar-staging.vector.im/_matrix/integrations/v1",
|
||||
"https://scalar-staging.vector.im/api",
|
||||
"https://scalar-staging.riot.im/scalar/api"
|
||||
]
|
||||
"integrations_ui_url": "https://scalar.vector.im/",
|
||||
"integrations_rest_url": "https://scalar.vector.im/api",
|
||||
"integrations_widgets_urls": [
|
||||
"https://scalar.vector.im/_matrix/integrations/v1",
|
||||
"https://scalar.vector.im/api",
|
||||
"https://scalar-staging.vector.im/_matrix/integrations/v1",
|
||||
"https://scalar-staging.vector.im/api",
|
||||
"https://scalar-staging.riot.im/scalar/api"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -393,9 +393,9 @@ If you would like to include a custom message when someone is reporting an event
|
|||
|
||||
```json
|
||||
{
|
||||
"report_event": {
|
||||
"admin_message_md": "Please be sure to review our [terms of service](https://example.org/terms) before reporting a message."
|
||||
}
|
||||
"report_event": {
|
||||
"admin_message_md": "Please be sure to review our [terms of service](https://example.org/terms) before reporting a message."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -403,9 +403,7 @@ To add additional "terms and conditions" links throughout the app, use the follo
|
|||
|
||||
```json
|
||||
{
|
||||
"terms_and_conditions_links": [
|
||||
{ "text": "Code of conduct", "url": "https://example.org/code-of-conduct" }
|
||||
]
|
||||
"terms_and_conditions_links": [{ "text": "Code of conduct", "url": "https://example.org/code-of-conduct" }]
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -422,7 +420,7 @@ analytics are deemed impossible and the user won't be asked to opt in to the sys
|
|||
There are additional root-level options which can be specified:
|
||||
|
||||
1. `analytics_owner`: the company name used in dialogs talking about analytics - this defaults to `brand`,
|
||||
and is useful when the provider of analytics is different from the provider of the Element instance.
|
||||
and is useful when the provider of analytics is different from the provider of the Element instance.
|
||||
2. `privacy_policy_url`: URL to the privacy policy including the analytics collection policy.
|
||||
|
||||
## Server hosting links
|
||||
|
|
@ -435,26 +433,26 @@ will not be shown to the user.
|
|||
of `utm_campaign` to denote which link the user clicked on within the app. Only ever applies to matrix.org users specifically.
|
||||
2. `host_signup`: Optional configuration for an account importer to your hosting platform. The API surface of this is not documented
|
||||
at the moment, but can be configured with the following subproperties:
|
||||
1. `brand`: The brand name to use.
|
||||
2. `url`: The iframe URL for the importer.
|
||||
3. `domains`: The homeserver domains to show the importer to.
|
||||
4. `cookie_policy_url`: The URL to the cookie policy for the importer.
|
||||
5. `privacy_policy_url`: The URL to the privacy policy for the importer.
|
||||
6. `terms_of_service_url`: The URL to the terms of service for the importer.
|
||||
1. `brand`: The brand name to use.
|
||||
2. `url`: The iframe URL for the importer.
|
||||
3. `domains`: The homeserver domains to show the importer to.
|
||||
4. `cookie_policy_url`: The URL to the cookie policy for the importer.
|
||||
5. `privacy_policy_url`: The URL to the privacy policy for the importer.
|
||||
6. `terms_of_service_url`: The URL to the terms of service for the importer.
|
||||
|
||||
If you're looking to mirror a setup from our production/development environments, the following config should be used:
|
||||
|
||||
```json
|
||||
{
|
||||
"hosting_signup_link": "https://element.io/matrix-services?utm_source=element-web&utm_medium=web",
|
||||
"host_signup": {
|
||||
"brand": "Element Home",
|
||||
"domains": [ "matrix.org" ],
|
||||
"url": "https://ems.element.io/element-home/in-app-loader",
|
||||
"cookie_policy_url": "https://element.io/cookie-policy",
|
||||
"privacy_policy_url": "https://element.io/privacy",
|
||||
"terms_of_service_url": "https://element.io/terms-of-service"
|
||||
}
|
||||
"hosting_signup_link": "https://element.io/matrix-services?utm_source=element-web&utm_medium=web",
|
||||
"host_signup": {
|
||||
"brand": "Element Home",
|
||||
"domains": ["matrix.org"],
|
||||
"url": "https://ems.element.io/element-home/in-app-loader",
|
||||
"cookie_policy_url": "https://element.io/cookie-policy",
|
||||
"privacy_policy_url": "https://element.io/privacy",
|
||||
"terms_of_service_url": "https://element.io/terms-of-service"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -467,10 +465,10 @@ set this value to the following at a minimum:
|
|||
|
||||
```json
|
||||
{
|
||||
"enable_presence_by_hs_url": {
|
||||
"https://matrix.org": false,
|
||||
"https://matrix-client.matrix.org": false
|
||||
}
|
||||
"enable_presence_by_hs_url": {
|
||||
"https://matrix.org": false,
|
||||
"https://matrix-client.matrix.org": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -487,8 +485,8 @@ Element will check multiple sources when looking for an identity server to use i
|
|||
the following order of preference:
|
||||
|
||||
1. The identity server set in the user's account data
|
||||
* For a new user, no value is present in their account data. It is only set
|
||||
if the user visits Settings and manually changes their identity server.
|
||||
- For a new user, no value is present in their account data. It is only set
|
||||
if the user visits Settings and manually changes their identity server.
|
||||
2. The identity server provided by the `.well-known` lookup that occurred at
|
||||
login
|
||||
3. The identity server provided by the Riot config file
|
||||
|
|
@ -514,40 +512,40 @@ preferences.
|
|||
|
||||
Currently, the following UI feature flags are supported:
|
||||
|
||||
* `UIFeature.urlPreviews` - Whether URL previews are enabled across the entire application.
|
||||
* `UIFeature.feedback` - Whether prompts to supply feedback are shown.
|
||||
* `UIFeature.voip` - Whether or not VoIP is shown readily to the user. When disabled,
|
||||
Jitsi widgets will still work though they cannot easily be added.
|
||||
* `UIFeature.widgets` - Whether or not widgets will be shown.
|
||||
* `UIFeature.flair` - Whether or not community flair is shown in rooms.
|
||||
* `UIFeature.communities` - Whether or not to show any UI related to communities. Implicitly
|
||||
disables `UIFeature.flair` when disabled.
|
||||
* `UIFeature.advancedSettings` - Whether or not sections titled "advanced" in room and
|
||||
user settings are shown to the user.
|
||||
* `UIFeature.shareQrCode` - Whether or not the QR code on the share room/event dialog
|
||||
is shown.
|
||||
* `UIFeature.shareSocial` - Whether or not the social icons on the share room/event dialog
|
||||
are shown.
|
||||
* `UIFeature.identityServer` - Whether or not functionality requiring an identity server
|
||||
is shown. When disabled, the user will not be able to interact with the identity
|
||||
server (sharing email addresses, 3PID invites, etc).
|
||||
* `UIFeature.thirdPartyId` - Whether or not UI relating to third party identifiers (3PIDs)
|
||||
is shown. Typically this is considered "contact information" on the homeserver, and is
|
||||
not directly related to the identity server.
|
||||
* `UIFeature.registration` - Whether or not the registration page is accessible. Typically
|
||||
useful if accounts are managed externally.
|
||||
* `UIFeature.passwordReset` - Whether or not the password reset page is accessible. Typically
|
||||
useful if accounts are managed externally.
|
||||
* `UIFeature.deactivate` - Whether or not the deactivate account button is accessible. Typically
|
||||
useful if accounts are managed externally.
|
||||
* `UIFeature.advancedEncryption` - Whether or not advanced encryption options are shown to the
|
||||
user.
|
||||
* `UIFeature.roomHistorySettings` - Whether or not the room history settings are shown to the user.
|
||||
This should only be used if the room history visibility options are managed by the server.
|
||||
* `UIFeature.TimelineEnableRelativeDates` - Display relative date separators (eg: 'Today', 'Yesterday') in the
|
||||
timeline for recent messages. When false day dates will be used.
|
||||
* `UIFeature.BulkUnverifiedSessionsReminder` - Display popup reminders to verify or remove unverified sessions. Defaults
|
||||
to true.
|
||||
- `UIFeature.urlPreviews` - Whether URL previews are enabled across the entire application.
|
||||
- `UIFeature.feedback` - Whether prompts to supply feedback are shown.
|
||||
- `UIFeature.voip` - Whether or not VoIP is shown readily to the user. When disabled,
|
||||
Jitsi widgets will still work though they cannot easily be added.
|
||||
- `UIFeature.widgets` - Whether or not widgets will be shown.
|
||||
- `UIFeature.flair` - Whether or not community flair is shown in rooms.
|
||||
- `UIFeature.communities` - Whether or not to show any UI related to communities. Implicitly
|
||||
disables `UIFeature.flair` when disabled.
|
||||
- `UIFeature.advancedSettings` - Whether or not sections titled "advanced" in room and
|
||||
user settings are shown to the user.
|
||||
- `UIFeature.shareQrCode` - Whether or not the QR code on the share room/event dialog
|
||||
is shown.
|
||||
- `UIFeature.shareSocial` - Whether or not the social icons on the share room/event dialog
|
||||
are shown.
|
||||
- `UIFeature.identityServer` - Whether or not functionality requiring an identity server
|
||||
is shown. When disabled, the user will not be able to interact with the identity
|
||||
server (sharing email addresses, 3PID invites, etc).
|
||||
- `UIFeature.thirdPartyId` - Whether or not UI relating to third party identifiers (3PIDs)
|
||||
is shown. Typically this is considered "contact information" on the homeserver, and is
|
||||
not directly related to the identity server.
|
||||
- `UIFeature.registration` - Whether or not the registration page is accessible. Typically
|
||||
useful if accounts are managed externally.
|
||||
- `UIFeature.passwordReset` - Whether or not the password reset page is accessible. Typically
|
||||
useful if accounts are managed externally.
|
||||
- `UIFeature.deactivate` - Whether or not the deactivate account button is accessible. Typically
|
||||
useful if accounts are managed externally.
|
||||
- `UIFeature.advancedEncryption` - Whether or not advanced encryption options are shown to the
|
||||
user.
|
||||
- `UIFeature.roomHistorySettings` - Whether or not the room history settings are shown to the user.
|
||||
This should only be used if the room history visibility options are managed by the server.
|
||||
- `UIFeature.TimelineEnableRelativeDates` - Display relative date separators (eg: 'Today', 'Yesterday') in the
|
||||
timeline for recent messages. When false day dates will be used.
|
||||
- `UIFeature.BulkUnverifiedSessionsReminder` - Display popup reminders to verify or remove unverified sessions. Defaults
|
||||
to true.
|
||||
|
||||
## Undocumented / developer options
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,6 @@ The home page can be overridden in `config.json` to provide all users of an elem
|
|||
}
|
||||
```
|
||||
|
||||
|
||||
## `home.html` Example
|
||||
|
||||
The following is a simple example for a custom `home.html`:
|
||||
|
|
@ -62,4 +61,3 @@ It may be needed to set CORS headers for the `home.html` to enable element-deskt
|
|||
```
|
||||
add_header Access-Control-Allow-Origin *;
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ maintenance.
|
|||
|
||||
**Note**: The project deliberately does not exclude `customisations.json` from Git.
|
||||
This is to ensure that in shared projects it's possible to have a common config. By
|
||||
default, Element Web does *not* ship with this file to prevent conflicts.
|
||||
default, Element Web does _not_ ship with this file to prevent conflicts.
|
||||
|
||||
### Custom components
|
||||
|
||||
|
|
@ -41,9 +41,10 @@ that properties/state machines won't change.
|
|||
### Component visibility customisation
|
||||
|
||||
UI for some actions can be hidden via the ComponentVisibility customisation:
|
||||
- inviting users to rooms and spaces,
|
||||
- creating rooms,
|
||||
- creating spaces,
|
||||
|
||||
- inviting users to rooms and spaces,
|
||||
- creating rooms,
|
||||
- creating spaces,
|
||||
|
||||
To customise visibility create a customisation module from [ComponentVisibility](https://github.com/matrix-org/matrix-react-sdk/blob/master/src/customisations/ComponentVisibility.ts) following the instructions above.
|
||||
|
||||
|
|
@ -55,6 +56,7 @@ might be shown to the user, but they won't have permission to invite users to
|
|||
the current room: the button will appear disabled.
|
||||
|
||||
For example, to only allow users who meet a certain condition to create spaces:
|
||||
|
||||
```typescript
|
||||
function shouldShowComponent(component: UIComponent): boolean {
|
||||
if (component === UIComponent.CreateSpaces) {
|
||||
|
|
@ -65,4 +67,5 @@ function shouldShowComponent(component: UIComponent): boolean {
|
|||
return true;
|
||||
}
|
||||
```
|
||||
|
||||
In this example, all UI related to creating a space will be hidden unless the users meets the custom condition.
|
||||
|
|
|
|||
18
docs/e2ee.md
18
docs/e2ee.md
|
|
@ -10,9 +10,9 @@ Set the following on your homeserver's
|
|||
|
||||
```json
|
||||
{
|
||||
"io.element.e2ee": {
|
||||
"default": false
|
||||
}
|
||||
"io.element.e2ee": {
|
||||
"default": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -29,9 +29,9 @@ following on your homeserver's `/.well-known/matrix/client` config:
|
|||
|
||||
```json
|
||||
{
|
||||
"io.element.e2ee": {
|
||||
"secure_backup_required": true
|
||||
}
|
||||
"io.element.e2ee": {
|
||||
"secure_backup_required": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -44,9 +44,9 @@ only offer one of these, you can signal this via the
|
|||
|
||||
```json
|
||||
{
|
||||
"io.element.e2ee": {
|
||||
"secure_backup_setup_methods": ["passphrase"]
|
||||
}
|
||||
"io.element.e2ee": {
|
||||
"secure_backup_setup_methods": ["passphrase"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@ flexibility and control over when and where those features are enabled.
|
|||
|
||||
For example, flags make the following things possible:
|
||||
|
||||
* Extended testing of a feature via labs on develop
|
||||
* Enabling features when ready instead of the first moment the code is released
|
||||
* Testing a feature with a specific set of users (by enabling only on a specific
|
||||
Element instance)
|
||||
- Extended testing of a feature via labs on develop
|
||||
- Enabling features when ready instead of the first moment the code is released
|
||||
- Testing a feature with a specific set of users (by enabling only on a specific
|
||||
Element instance)
|
||||
|
||||
The size of the feature controlled by a feature flag may vary widely: it could
|
||||
be a large project like reactions or a smaller change to an existing algorithm.
|
||||
|
|
@ -37,6 +37,7 @@ When starting work on a feature, we should create a matching feature flag:
|
|||
1. Add a new
|
||||
[setting](https://github.com/matrix-org/matrix-react-sdk/blob/develop/src/settings/Settings.tsx)
|
||||
of the form:
|
||||
|
||||
```js
|
||||
"feature_cats": {
|
||||
isFeature: true,
|
||||
|
|
@ -45,10 +46,13 @@ When starting work on a feature, we should create a matching feature flag:
|
|||
default: false,
|
||||
},
|
||||
```
|
||||
|
||||
2. Check whether the feature is enabled as appropriate:
|
||||
|
||||
```js
|
||||
SettingsStore.getValue("feature_cats")
|
||||
SettingsStore.getValue("feature_cats");
|
||||
```
|
||||
|
||||
3. Document the feature in the [labs documentation](https://github.com/vector-im/element-web/blob/develop/docs/labs.md)
|
||||
|
||||
With these steps completed, the feature is disabled by default, but can be
|
||||
|
|
@ -88,12 +92,14 @@ cover these cases, change the setting's `default` in `Settings.tsx` to `true`.
|
|||
Once we're confident that a feature is working well, we should remove or convert the flag.
|
||||
|
||||
If the feature is meant to be turned off/on by the user:
|
||||
|
||||
1. Remove `isFeature` from the [setting](https://github.com/matrix-org/matrix-react-sdk/blob/develop/src/settings/Settings.ts)
|
||||
2. Change the `default` to `true` (if desired).
|
||||
3. Remove the feature from the [labs documentation](https://github.com/vector-im/element-web/blob/develop/docs/labs.md)
|
||||
4. Celebrate! 🥳
|
||||
|
||||
If the feature is meant to be forced on (non-configurable):
|
||||
|
||||
1. Remove the [setting](https://github.com/matrix-org/matrix-react-sdk/blob/develop/src/settings/Settings.ts)
|
||||
2. Remove all `getValue` lines that test for the feature.
|
||||
3. Remove the feature from the [labs documentation](https://github.com/vector-im/element-web/blob/develop/docs/labs.md)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Jitsi wrapper developer docs
|
||||
|
||||
*If you're looking for information on how to set up Jitsi in your Element, see
|
||||
[jitsi.md](./jitsi.md) instead.*
|
||||
_If you're looking for information on how to set up Jitsi in your Element, see
|
||||
[jitsi.md](./jitsi.md) instead._
|
||||
|
||||
These docs are for developers wondering how the different conference buttons work
|
||||
within Element. If you're not a developer, you're probably looking for [jitsi.md](./jitsi.md).
|
||||
|
|
@ -46,24 +46,24 @@ end up creating a widget with a URL like `https://integrations.example.org?widge
|
|||
The integration manager's wrapper will typically have another iframe to isolate the
|
||||
widget from the client by yet another layer. The wrapper often provides other functionality
|
||||
which might not be available on the embedded site, such as a fullscreen button or the
|
||||
communication layer with the client (all widgets *should* be talking to the client
|
||||
communication layer with the client (all widgets _should_ be talking to the client
|
||||
over `postMessage`, even if they aren't going to be using the widget APIs).
|
||||
|
||||
Widgets added with the `/addwidget` command will *not* be wrapped as they are not going
|
||||
through an integration manager. The widgets themselves *should* also work outside of
|
||||
Widgets added with the `/addwidget` command will _not_ be wrapped as they are not going
|
||||
through an integration manager. The widgets themselves _should_ also work outside of
|
||||
Element. Widgets currently have a "pop out" button which opens them in a new tab and
|
||||
therefore have no connection back to Riot.
|
||||
|
||||
## Jitsi widgets from integration managers
|
||||
|
||||
Integration managers will create an entire widget event and send it over `postMessage`
|
||||
for the client to add to the room. This means that the integration manager gets to
|
||||
for the client to add to the room. This means that the integration manager gets to
|
||||
decide the conference domain, conference name, and other aspects of the widget. As
|
||||
a result, users can end up with a Jitsi widget that does not use the same conference
|
||||
server they specified in their config.json - this is expected.
|
||||
|
||||
Some integration managers allow the user to change the conference name while others
|
||||
will generate one for the user.
|
||||
will generate one for the user.
|
||||
|
||||
## Jitsi widgets generated by Element itself
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ The Jitsi widget created by Element uses a local `jitsi.html` wrapper (or one ho
|
|||
required `postMessage` calls are fulfilled.
|
||||
|
||||
**Note**: Per [jitsi.md](./jitsi.md) the `preferredDomain` can also come from the server's
|
||||
client .well-known data.
|
||||
client .well-known data.
|
||||
|
||||
## The Jitsi wrapper in Element
|
||||
|
||||
|
|
@ -92,9 +92,9 @@ and less risky to load. The local wrapper URL is populated with the conference i
|
|||
from the original widget (which could be a v1 or v2 widget) so the user joins the right
|
||||
call.
|
||||
|
||||
Critically, when the widget URL is reconstructed it does *not* take into account the
|
||||
Critically, when the widget URL is reconstructed it does _not_ take into account the
|
||||
config.json's `preferredDomain` for Jitsi. If it did this, users would end up on different
|
||||
conference servers and therefore different calls entirely.
|
||||
conference servers and therefore different calls entirely.
|
||||
|
||||
**Note**: Per [jitsi.md](./jitsi.md) the `preferredDomain` can also come from the server's
|
||||
client .well-known data.
|
||||
|
|
|
|||
|
|
@ -24,13 +24,14 @@ Element will use the Jitsi server that is embedded in the widget, even if it is
|
|||
one you configured. This is because conference calls must be held on a single Jitsi
|
||||
server and cannot be split over multiple servers.
|
||||
|
||||
However, you can configure Element to *start* a conference with your Jitsi server by adding
|
||||
However, you can configure Element to _start_ a conference with your Jitsi server by adding
|
||||
to your [config](./config.md) the following:
|
||||
|
||||
```json
|
||||
{
|
||||
"jitsi": {
|
||||
"preferredDomain": "your.jitsi.example.org"
|
||||
}
|
||||
"jitsi": {
|
||||
"preferredDomain": "your.jitsi.example.org"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -46,11 +47,12 @@ domain will appear later in the URL as a configuration parameter.
|
|||
**Hint**: If you want everyone on your homeserver to use the same Jitsi server by
|
||||
default, and you are using element-web 1.6 or newer, set the following on your homeserver's
|
||||
`/.well-known/matrix/client` config:
|
||||
|
||||
```json
|
||||
{
|
||||
"im.vector.riot.jitsi": {
|
||||
"preferredDomain": "your.jitsi.example.org"
|
||||
}
|
||||
"im.vector.riot.jitsi": {
|
||||
"preferredDomain": "your.jitsi.example.org"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
Running in Kubernetes
|
||||
=====================
|
||||
# Running in Kubernetes
|
||||
|
||||
In case you would like to deploy element-web in a kubernetes cluster you can use
|
||||
the provided Kubernetes example below as a starting point. Note that this example assumes the
|
||||
|
|
@ -178,4 +177,3 @@ Then you can deploy it to your cluster with something like `kubectl apply -f my-
|
|||
number: 80
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ Switches to a new room search experience.
|
|||
|
||||
## Extensible events rendering (`feature_extensible_events`) [In Development]
|
||||
|
||||
*Intended for developer use only at the moment.*
|
||||
_Intended for developer use only at the moment._
|
||||
|
||||
Extensible Events are a [new event format](https://github.com/matrix-org/matrix-doc/pull/1767) which
|
||||
supports graceful fallback in unknown event types. Instead of rendering nothing or a blank space, events
|
||||
|
|
@ -159,7 +159,7 @@ Threading allows users to branch out a new conversation from the main timeline o
|
|||
|
||||
Threads can be access by clicking their summary below the root event on the room timeline. Users can find a comprehensive list of threads by click the icon on the room header button.
|
||||
|
||||
This feature might work in degraded mode if the homeserver a user is connected to does not advertise support for the unstable feature `org.matrix.msc3440` when calling the `/versions` API endpoint.
|
||||
This feature might work in degraded mode if the homeserver a user is connected to does not advertise support for the unstable feature `org.matrix.msc3440` when calling the `/versions` API endpoint.
|
||||
|
||||
## Video rooms (`feature_video_rooms`)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
## Memory leaks
|
||||
|
||||
Element usually emits slow behaviour just before it is about to crash. Getting a
|
||||
Element usually emits slow behaviour just before it is about to crash. Getting a
|
||||
memory snapshot (below) just before that happens is ideal in figuring out what
|
||||
is going wrong.
|
||||
|
||||
Common symptoms are clicking on a room and it feels like the tab froze and scrolling
|
||||
becoming jumpy/staggered.
|
||||
becoming jumpy/staggered.
|
||||
|
||||
If you receive a white screen (electron) or the chrome crash page, it is likely
|
||||
run out of memory and it is too late for a memory profile. Please do report when
|
||||
|
|
@ -22,8 +22,8 @@ and anything newer is still in the warmup stages of the app.
|
|||
|
||||
**Memory profiles can contain sensitive information.** If you are submitting a memory
|
||||
profile to us for debugging purposes, please pick the appropriate Element developer and
|
||||
send them over an encrypted private message. *Do not share your memory profile in
|
||||
public channels or with people you do not trust.*
|
||||
send them over an encrypted private message. _Do not share your memory profile in
|
||||
public channels or with people you do not trust._
|
||||
|
||||
### Taking a memory profile (Firefox)
|
||||
|
||||
|
|
|
|||
|
|
@ -34,6 +34,7 @@ our [ILAG module](https://github.com/vector-im/element-web-ilag-module) which wi
|
|||
structure of a module is and how it works.
|
||||
|
||||
The following requirements are key for any module:
|
||||
|
||||
1. The module must depend on `@matrix-org/react-sdk-module-api` (usually as a dev dependency).
|
||||
2. The module's `main` entrypoint must have a `default` export for the `RuntimeModule` instance, supporting a constructor
|
||||
which takes a single parameter: a `ModuleApi` instance. This instance is passed to `super()`.
|
||||
|
|
|
|||
|
|
@ -10,53 +10,53 @@ When reviewing code, here are some things we look for and also things we avoid:
|
|||
|
||||
### We review for
|
||||
|
||||
* Correctness
|
||||
* Performance
|
||||
* Accessibility
|
||||
* Security
|
||||
* Quality via automated and manual testing
|
||||
* Comments and documentation where needed
|
||||
* Sharing knowledge of different areas among the team
|
||||
* Ensuring it's something we're comfortable maintaining for the long term
|
||||
* Progress indicators and local echo where appropriate with network activity
|
||||
- Correctness
|
||||
- Performance
|
||||
- Accessibility
|
||||
- Security
|
||||
- Quality via automated and manual testing
|
||||
- Comments and documentation where needed
|
||||
- Sharing knowledge of different areas among the team
|
||||
- Ensuring it's something we're comfortable maintaining for the long term
|
||||
- Progress indicators and local echo where appropriate with network activity
|
||||
|
||||
### We should avoid
|
||||
|
||||
* Style nits that are already handled by the linter
|
||||
* Dramatically increasing scope
|
||||
- Style nits that are already handled by the linter
|
||||
- Dramatically increasing scope
|
||||
|
||||
### Good practices
|
||||
|
||||
* Use empathetic language
|
||||
* See also [Mindful Communication in Code
|
||||
Reviews](https://kickstarter.engineering/a-guide-to-mindful-communication-in-code-reviews-48aab5282e5e)
|
||||
and [How to Do Code Reviews Like a Human](https://mtlynch.io/human-code-reviews-1/)
|
||||
* Authors should prefer smaller commits for easier reviewing and bisection
|
||||
* Reviewers should be explicit about required versus optional changes
|
||||
* Reviews are conversations and the PR author should feel comfortable
|
||||
discussing and pushing back on changes before making them
|
||||
* Reviewers are encouraged to ask for tests where they believe it is reasonable
|
||||
* Core team should lead by example through their tone and language
|
||||
* Take the time to thank and point out good code changes
|
||||
* Using softer language like "please" and "what do you think?" goes a long way
|
||||
towards making others feel like colleagues working towards a common goal
|
||||
- Use empathetic language
|
||||
- See also [Mindful Communication in Code
|
||||
Reviews](https://kickstarter.engineering/a-guide-to-mindful-communication-in-code-reviews-48aab5282e5e)
|
||||
and [How to Do Code Reviews Like a Human](https://mtlynch.io/human-code-reviews-1/)
|
||||
- Authors should prefer smaller commits for easier reviewing and bisection
|
||||
- Reviewers should be explicit about required versus optional changes
|
||||
- Reviews are conversations and the PR author should feel comfortable
|
||||
discussing and pushing back on changes before making them
|
||||
- Reviewers are encouraged to ask for tests where they believe it is reasonable
|
||||
- Core team should lead by example through their tone and language
|
||||
- Take the time to thank and point out good code changes
|
||||
- Using softer language like "please" and "what do you think?" goes a long way
|
||||
towards making others feel like colleagues working towards a common goal
|
||||
|
||||
### Workflow
|
||||
|
||||
* Authors should request review from the element-web team by default (if someone on
|
||||
the team is clearly the expert in an area, a direct review request to them may
|
||||
be more appropriate)
|
||||
* Reviewers should remove the team review request and request review from
|
||||
themselves when starting a review to avoid double review
|
||||
* If there are multiple related PRs authors should reference each of the PRs in
|
||||
the others before requesting review. Reviewers might start reviewing from
|
||||
different places and could miss other required PRs.
|
||||
* Avoid force pushing to a PR after the first round of review
|
||||
* Use the GitHub default of merge commits when landing (avoid alternate options
|
||||
like squash or rebase)
|
||||
* PR author merges after review (assuming they have write access)
|
||||
* Assign issues only when in progress to indicate to others what can be picked
|
||||
up
|
||||
- Authors should request review from the element-web team by default (if someone on
|
||||
the team is clearly the expert in an area, a direct review request to them may
|
||||
be more appropriate)
|
||||
- Reviewers should remove the team review request and request review from
|
||||
themselves when starting a review to avoid double review
|
||||
- If there are multiple related PRs authors should reference each of the PRs in
|
||||
the others before requesting review. Reviewers might start reviewing from
|
||||
different places and could miss other required PRs.
|
||||
- Avoid force pushing to a PR after the first round of review
|
||||
- Use the GitHub default of merge commits when landing (avoid alternate options
|
||||
like squash or rebase)
|
||||
- PR author merges after review (assuming they have write access)
|
||||
- Assign issues only when in progress to indicate to others what can be picked
|
||||
up
|
||||
|
||||
## Code Quality
|
||||
|
||||
|
|
@ -64,10 +64,10 @@ In the past, we have occasionally written different kinds of tests for
|
|||
Element and the SDKs, but it hasn't been a consistent focus. Going forward, we'd
|
||||
like to change that.
|
||||
|
||||
* For new features, code reviewers will expect some form of automated testing to
|
||||
be included by default
|
||||
* For bug fixes, regression tests are of course great to have, but we don't want
|
||||
to block fixes on this, so we won't require them at this time
|
||||
- For new features, code reviewers will expect some form of automated testing to
|
||||
be included by default
|
||||
- For bug fixes, regression tests are of course great to have, but we don't want
|
||||
to block fixes on this, so we won't require them at this time
|
||||
|
||||
The above policy is not a strict rule, but instead it's meant to be a
|
||||
conversation between the author and reviewer. As an author, try to think about
|
||||
|
|
@ -104,10 +104,10 @@ perspective.
|
|||
In more detail, our usual process for changes that affect the UI or alter user
|
||||
functionality is:
|
||||
|
||||
* For changes that will go live when merged, always flag Design and Product
|
||||
teams as appropriate
|
||||
* For changes guarded by a feature flag, Design and Product review is not
|
||||
required (though may still be useful) since we can continue tweaking
|
||||
- For changes that will go live when merged, always flag Design and Product
|
||||
teams as appropriate
|
||||
- For changes guarded by a feature flag, Design and Product review is not
|
||||
required (though may still be useful) since we can continue tweaking
|
||||
|
||||
As it can be difficult to review design work from looking at just the changed
|
||||
files in a PR, a [preview site](./pr-previews.md) that includes your changes
|
||||
|
|
|
|||
|
|
@ -1,31 +1,29 @@
|
|||
Theming Element
|
||||
============
|
||||
# Theming Element
|
||||
|
||||
Themes are a very basic way of providing simple alternative look & feels to the
|
||||
Element app via CSS & custom imagery.
|
||||
|
||||
They are *NOT* co be confused with 'skins', which describe apps which sit on top
|
||||
They are _NOT_ co be confused with 'skins', which describe apps which sit on top
|
||||
of matrix-react-sdk - e.g. in theory Element itself is a react-sdk skin.
|
||||
As of March 2022, skins are not fully supported; Element is the only available skin.
|
||||
|
||||
To define a theme for Element:
|
||||
|
||||
1. Pick a name, e.g. `teal`. at time of writing we have `light` and `dark`.
|
||||
2. Fork `src/skins/vector/css/themes/dark.pcss` to be `teal.pcss`
|
||||
3. Fork `src/skins/vector/css/themes/_base.pcss` to be `_teal.pcss`
|
||||
4. Override variables in `_teal.pcss` as desired. You may wish to delete ones
|
||||
1. Pick a name, e.g. `teal`. at time of writing we have `light` and `dark`.
|
||||
2. Fork `src/skins/vector/css/themes/dark.pcss` to be `teal.pcss`
|
||||
3. Fork `src/skins/vector/css/themes/_base.pcss` to be `_teal.pcss`
|
||||
4. Override variables in `_teal.pcss` as desired. You may wish to delete ones
|
||||
which don't differ from `_base.pcss`, to make it clear which are being
|
||||
overridden. If every single colour is being changed (as per `_dark.pcss`)
|
||||
then you might as well keep them all.
|
||||
5. Add the theme to the list of entrypoints in webpack.config.js
|
||||
6. Add the theme to the list of themes in matrix-react-sdk's UserSettings.js
|
||||
7. Sit back and admire your handywork.
|
||||
5. Add the theme to the list of entrypoints in webpack.config.js
|
||||
6. Add the theme to the list of themes in matrix-react-sdk's UserSettings.js
|
||||
7. Sit back and admire your handywork.
|
||||
|
||||
In future, the assets for a theme will probably be gathered together into a
|
||||
single directory tree.
|
||||
|
||||
Custom Themes
|
||||
=============
|
||||
# Custom Themes
|
||||
|
||||
Themes derived from the built in themes may also be defined in settings.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,11 +2,11 @@
|
|||
|
||||
## Requirements
|
||||
|
||||
- A working [Development Setup](../README.md#setting-up-a-dev-environment)
|
||||
- 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
|
||||
- A working [Development Setup](../README.md#setting-up-a-dev-environment)
|
||||
- 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
|
||||
|
||||
|
|
@ -15,6 +15,7 @@ Translating strings are done with the `_t()` function found in matrix-react-sdk/
|
|||
Basically, whenever a translatable string is introduced, you should call either `_t()` immediately OR `_td()` and later `_t()`.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
// Module-level constant
|
||||
const COLORS = {
|
||||
|
|
@ -30,10 +31,10 @@ function getColorName(hex) {
|
|||
|
||||
## 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. (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).
|
||||
|
||||
## Editing existing strings
|
||||
|
||||
|
|
@ -43,21 +44,21 @@ function getColorName(hex) {
|
|||
|
||||
## 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(STRING)` use `_t(STRING, {})`
|
||||
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 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.
|
||||
1. Add it to the array in `_t` for example `_t(STRING, {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).
|
||||
- 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> })``.
|
||||
- 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).
|
||||
- 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> })`.
|
||||
|
||||
## Things to know/Style Guides
|
||||
|
||||
- Do not use `_t()` inside ``getDefaultProps``: the translations aren't loaded when `getDefaultProps` is called, leading to missing translations. Use `_td()` to indicate that `_t()` will be called on the string later.
|
||||
- If using translated strings as constants, translated strings can't be in constants loaded at class-load time since the translations won't be loaded. Mark the strings using `_td()` instead and perform the actual translation later.
|
||||
- If a string is presented in the UI with punctuation like a full stop, include this in the translation strings, since punctuation varies between languages too.
|
||||
- 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.
|
||||
- Do not use `_t()` inside `getDefaultProps`: the translations aren't loaded when `getDefaultProps` is called, leading to missing translations. Use `_td()` to indicate that `_t()` will be called on the string later.
|
||||
- If using translated strings as constants, translated strings can't be in constants loaded at class-load time since the translations won't be loaded. Mark the strings using `_td()` instead and perform the actual translation later.
|
||||
- If a string is presented in the UI with punctuation like a full stop, include this in the translation strings, since punctuation varies between languages too.
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -2,15 +2,15 @@
|
|||
|
||||
## Requirements
|
||||
|
||||
- Web Browser
|
||||
- Be able to understand English
|
||||
- Be able to understand the language you want to translate Element into
|
||||
- Web Browser
|
||||
- Be able to understand English
|
||||
- Be able to understand the language you want to translate Element into
|
||||
|
||||
## Step 0: Join #element-translations:matrix.org
|
||||
|
||||
1. Come and join https://matrix.to/#/#element-translations:matrix.org for general discussion
|
||||
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 :)
|
||||
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
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ If your language is listed go to Step 2a and if not go to Step 2b
|
|||
## Step 2a: Helping on existing languages.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
Head to the explanations under Steb 2b
|
||||
|
|
@ -35,7 +35,7 @@ Head to the explanations under Steb 2b
|
|||
## Step 2b: Adding a new language
|
||||
|
||||
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
|
||||
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
|
||||
|
|
@ -52,13 +52,12 @@ The yellow button has to be used if you are unsure about the translation but you
|
|||
|
||||
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.
|
||||
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
|
||||
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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue