Update all non-major dependencies (#28556)
* Update all non-major dependencies * Prettier Signed-off-by: Michael Telatynski <7t3chguy@gmail.com> --------- Signed-off-by: Michael Telatynski <7t3chguy@gmail.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
This commit is contained in:
renovate[bot]
GitHub
parent
4f276c1690
commit
418f121f96
86 changed files with 820 additions and 926 deletions
|
|
@ -1,55 +1,55 @@
|
|||
# Summary
|
||||
|
||||
- [Introduction](../README.md)
|
||||
- [Introduction](../README.md)
|
||||
|
||||
# Usage
|
||||
|
||||
- [Betas](betas.md)
|
||||
- [Labs](labs.md)
|
||||
- [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)
|
||||
- [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)
|
||||
- [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)
|
||||
- [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)
|
||||
- [Playwright end to end tests](playwright.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)
|
||||
- [App load order](app-load.md)
|
||||
- [Translation](translating-dev.md)
|
||||
- [Theming](theming.md)
|
||||
- [Playwright end to end tests](playwright.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)
|
||||
|
||||
# Deep dive
|
||||
|
||||
- [Skinning](skinning.md)
|
||||
- [Cider editor](ciderEditor.md)
|
||||
- [Iconography](icons.md)
|
||||
- [Jitsi](jitsi.md)
|
||||
- [Local echo](local-echo-dev.md)
|
||||
- [Media](media-handling.md)
|
||||
- [Room List Store](room-list-store.md)
|
||||
- [Scrolling](scrolling.md)
|
||||
- [Usercontent](usercontent.md)
|
||||
- [Widget layouts](widget-layouts.md)
|
||||
- [Skinning](skinning.md)
|
||||
- [Cider editor](ciderEditor.md)
|
||||
- [Iconography](icons.md)
|
||||
- [Jitsi](jitsi.md)
|
||||
- [Local echo](local-echo-dev.md)
|
||||
- [Media](media-handling.md)
|
||||
- [Room List Store](room-list-store.md)
|
||||
- [Scrolling](scrolling.md)
|
||||
- [Usercontent](usercontent.md)
|
||||
- [Widget layouts](widget-layouts.md)
|
||||
|
|
|
|||
|
|
@ -61,18 +61,18 @@ flowchart TD
|
|||
|
||||
Key:
|
||||
|
||||
- Parallelogram: async/await task
|
||||
- Box: sync task
|
||||
- Diamond: conditional branch
|
||||
- Circle: 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
|
||||
- Circle: 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:
|
||||
|
||||
|
|
|
|||
|
|
@ -32,19 +32,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/element-hq/teams/product/members) or
|
||||
[Design](https://github.com/orgs/element-hq/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/element-hq/teams/product/members) or
|
||||
[Design](https://github.com/orgs/element-hq/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
|
||||
|
|
|
|||
|
|
@ -455,7 +455,7 @@ If you would like to use Scalar, the integration manager maintained by Element,
|
|||
|
||||
For widgets in general (from an integration manager or not) there is also:
|
||||
|
||||
- `default_widget_container_height`
|
||||
- `default_widget_container_height`
|
||||
|
||||
This controls the height that the top widget panel initially appears as and is the height in pixels, default 280.
|
||||
|
||||
|
|
@ -551,38 +551,38 @@ 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.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.locationSharing` - Whether or not location sharing menus will be shown.
|
||||
- `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.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.locationSharing` - Whether or not location sharing menus will be shown.
|
||||
|
||||
## Undocumented / developer options
|
||||
|
||||
|
|
|
|||
|
|
@ -50,9 +50,9 @@ that properties/state machines won't change.
|
|||
|
||||
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/element-hq/element-web/blob/master/src/customisations/ComponentVisibility.ts) following the instructions above.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,9 +31,9 @@ Set the following on your homeserver's
|
|||
|
||||
When `force_disable` is true:
|
||||
|
||||
- all rooms will be created with encryption disabled, and it will not be possible to enable
|
||||
encryption from room settings.
|
||||
- any `io.element.e2ee.default` value will be disregarded.
|
||||
- all rooms will be created with encryption disabled, and it will not be possible to enable
|
||||
encryption from room settings.
|
||||
- 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 overridden.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -2,37 +2,37 @@
|
|||
|
||||
## Auto Complete
|
||||
|
||||
- Hitting tab tries to auto-complete the word before the caret as a room member
|
||||
- If no matching name is found, a visual bell is shown
|
||||
- @ + a letter opens auto complete for members starting with the given letter
|
||||
- When inserting a user pill at the start in the composer, a colon and space is appended to the pill
|
||||
- When inserting a user pill anywhere else in composer, only a space is appended to the pill
|
||||
- # + a letter opens auto complete for rooms starting with the given letter
|
||||
- : open auto complete for emoji
|
||||
- Pressing arrow-up/arrow-down while the autocomplete is open navigates between auto complete options
|
||||
- Pressing tab while the autocomplete is open goes to the next autocomplete option,
|
||||
wrapping around at the end after reverting to the typed text first.
|
||||
- Hitting tab tries to auto-complete the word before the caret as a room member
|
||||
- If no matching name is found, a visual bell is shown
|
||||
- @ + a letter opens auto complete for members starting with the given letter
|
||||
- When inserting a user pill at the start in the composer, a colon and space is appended to the pill
|
||||
- When inserting a user pill anywhere else in composer, only a space is appended to the pill
|
||||
- # + a letter opens auto complete for rooms starting with the given letter
|
||||
- : open auto complete for emoji
|
||||
- Pressing arrow-up/arrow-down while the autocomplete is open navigates between auto complete options
|
||||
- Pressing tab while the autocomplete is open goes to the next autocomplete option,
|
||||
wrapping around at the end after reverting to the typed text first.
|
||||
|
||||
## Formatting
|
||||
|
||||
- When selecting text, a formatting bar appears above the selection.
|
||||
- The formatting bar allows to format the selected test as:
|
||||
bold, italic, strikethrough, a block quote, and a code block (inline if no linebreak is selected).
|
||||
- Formatting is applied as markdown syntax.
|
||||
- Hitting ctrl/cmd+B also marks the selected text as bold
|
||||
- Hitting ctrl/cmd+I also marks the selected text as italic
|
||||
- Hitting ctrl/cmd+> also marks the selected text as a blockquote
|
||||
- When selecting text, a formatting bar appears above the selection.
|
||||
- The formatting bar allows to format the selected test as:
|
||||
bold, italic, strikethrough, a block quote, and a code block (inline if no linebreak is selected).
|
||||
- Formatting is applied as markdown syntax.
|
||||
- Hitting ctrl/cmd+B also marks the selected text as bold
|
||||
- Hitting ctrl/cmd+I also marks the selected text as italic
|
||||
- Hitting ctrl/cmd+> also marks the selected text as a blockquote
|
||||
|
||||
## Misc
|
||||
|
||||
- When hitting the arrow-up button while having the caret at the start in the composer,
|
||||
the last message sent by the syncing user is edited.
|
||||
- Clicking a display name on an event in the timeline inserts a user pill into the composer
|
||||
- Emoticons (like :-), >:-), :-/, ...) are replaced by emojis while typing if the relevant setting is enabled
|
||||
- Typing in the composer sends typing notifications in the room
|
||||
- Pressing ctrl/mod+z and ctrl/mod+y undoes/redoes modifications
|
||||
- Pressing shift+enter inserts a line break
|
||||
- Pressing enter sends the message.
|
||||
- Choosing "Quote" in the context menu of an event inserts a quote of the event body in the composer.
|
||||
- Choosing "Reply" in the context menu of an event shows a preview above the composer to reply to.
|
||||
- Pressing alt+arrow up/arrow down navigates in previously sent messages, putting them in the composer.
|
||||
- When hitting the arrow-up button while having the caret at the start in the composer,
|
||||
the last message sent by the syncing user is edited.
|
||||
- Clicking a display name on an event in the timeline inserts a user pill into the composer
|
||||
- Emoticons (like :-), >:-), :-/, ...) are replaced by emojis while typing if the relevant setting is enabled
|
||||
- Typing in the composer sends typing notifications in the room
|
||||
- Pressing ctrl/mod+z and ctrl/mod+y undoes/redoes modifications
|
||||
- Pressing shift+enter inserts a line break
|
||||
- Pressing enter sends the message.
|
||||
- Choosing "Quote" in the context menu of an event inserts a quote of the event body in the composer.
|
||||
- Choosing "Reply" in the context menu of an event shows a preview above the composer to reply to.
|
||||
- Pressing alt+arrow up/arrow down navigates in previously sent messages, putting them in the composer.
|
||||
|
|
|
|||
|
|
@ -8,9 +8,9 @@ Icons have `role="presentation"` and `aria-hidden` automatically applied. These
|
|||
|
||||
SVG file recommendations:
|
||||
|
||||
- Colours should not be defined absolutely. Use `currentColor` instead.
|
||||
- SVG files should be taken from the design compound as they are. Some icons contain special padding.
|
||||
This means that there should be icons for each size, e.g. warning-16px and warning-32px.
|
||||
- Colours should not be defined absolutely. Use `currentColor` instead.
|
||||
- SVG files should be taken from the design compound as they are. Some icons contain special padding.
|
||||
This means that there should be icons for each size, e.g. warning-16px and warning-32px.
|
||||
|
||||
Example usage:
|
||||
|
||||
|
|
|
|||
|
|
@ -81,27 +81,27 @@ which takes several parameters:
|
|||
|
||||
_Query string_:
|
||||
|
||||
- `widgetId`: The ID of the widget. This is needed for communication back to the
|
||||
react-sdk.
|
||||
- `parentUrl`: The URL of the parent window. This is also needed for
|
||||
communication back to the react-sdk.
|
||||
- `widgetId`: The ID of the widget. This is needed for communication back to the
|
||||
react-sdk.
|
||||
- `parentUrl`: The URL of the parent window. This is also needed for
|
||||
communication back to the react-sdk.
|
||||
|
||||
_Hash/fragment (formatted as a query string)_:
|
||||
|
||||
- `conferenceDomain`: The domain to connect Jitsi Meet to.
|
||||
- `conferenceId`: The room or conference ID to connect Jitsi Meet to.
|
||||
- `isAudioOnly`: Boolean for whether this is a voice-only conference. May not
|
||||
be present, should default to `false`.
|
||||
- `startWithAudioMuted`: Boolean for whether the calls start with audio
|
||||
muted. May not be present.
|
||||
- `startWithVideoMuted`: Boolean for whether the calls start with video
|
||||
muted. May not be present.
|
||||
- `displayName`: The display name of the user viewing the widget. May not
|
||||
be present or could be null.
|
||||
- `avatarUrl`: The HTTP(S) URL for the avatar of the user viewing the widget. May
|
||||
not be present or could be null.
|
||||
- `userId`: The MXID of the user viewing the widget. May not be present or could
|
||||
be null.
|
||||
- `conferenceDomain`: The domain to connect Jitsi Meet to.
|
||||
- `conferenceId`: The room or conference ID to connect Jitsi Meet to.
|
||||
- `isAudioOnly`: Boolean for whether this is a voice-only conference. May not
|
||||
be present, should default to `false`.
|
||||
- `startWithAudioMuted`: Boolean for whether the calls start with audio
|
||||
muted. May not be present.
|
||||
- `startWithVideoMuted`: Boolean for whether the calls start with video
|
||||
muted. May not be present.
|
||||
- `displayName`: The display name of the user viewing the widget. May not
|
||||
be present or could be null.
|
||||
- `avatarUrl`: The HTTP(S) URL for the avatar of the user viewing the widget. May
|
||||
not be present or could be null.
|
||||
- `userId`: The MXID of the user viewing the widget. May not be present or could
|
||||
be null.
|
||||
|
||||
The react-sdk will assume that `jitsi.html` is at the path of wherever it is currently
|
||||
being served. For example, `https://develop.element.io/jitsi.html` or `vector://webapp/jitsi.html`.
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@
|
|||
|
||||
## Contents
|
||||
|
||||
- How to run the tests
|
||||
- How the tests work
|
||||
- How to write great Playwright tests
|
||||
- Visual testing
|
||||
- How to run the tests
|
||||
- How the tests work
|
||||
- How to write great Playwright tests
|
||||
- Visual testing
|
||||
|
||||
## Running the Tests
|
||||
|
||||
|
|
@ -123,15 +123,15 @@ When a Synapse instance is started, it's given a config generated from one of th
|
|||
templates in `playwright/plugins/homeserver/synapse/templates`. There are a couple of special files
|
||||
in these templates:
|
||||
|
||||
- `homeserver.yaml`:
|
||||
Template substitution happens in this file. Template variables are:
|
||||
- `REGISTRATION_SECRET`: The secret used to register users via the REST API.
|
||||
- `MACAROON_SECRET_KEY`: Generated each time for security
|
||||
- `FORM_SECRET`: Generated each time for security
|
||||
- `PUBLIC_BASEURL`: The localhost url + port combination the synapse is accessible at
|
||||
- `localhost.signing.key`: A signing key is auto-generated and saved to this file.
|
||||
Config templates should not contain a signing key and instead assume that one will exist
|
||||
in this file.
|
||||
- `homeserver.yaml`:
|
||||
Template substitution happens in this file. Template variables are:
|
||||
- `REGISTRATION_SECRET`: The secret used to register users via the REST API.
|
||||
- `MACAROON_SECRET_KEY`: Generated each time for security
|
||||
- `FORM_SECRET`: Generated each time for security
|
||||
- `PUBLIC_BASEURL`: The localhost url + port combination the synapse is accessible at
|
||||
- `localhost.signing.key`: A signing key is auto-generated and saved to this file.
|
||||
Config templates should not contain a signing key and instead assume that one will exist
|
||||
in this file.
|
||||
|
||||
All other files in the template are copied recursively to `/data/`, so the file `foo.html`
|
||||
in a template can be referenced in the config as `/data/foo.html`.
|
||||
|
|
|
|||
|
|
@ -82,28 +82,28 @@ This label will automagically convert to `X-Release-Blocker` at the conclusion o
|
|||
|
||||
This release process revolves around our main repositories:
|
||||
|
||||
- [Element Desktop](https://github.com/element-hq/element-desktop/)
|
||||
- [Element Web](https://github.com/element-hq/element-web/)
|
||||
- [Matrix JS SDK](https://github.com/matrix-org/matrix-js-sdk/)
|
||||
- [Element Desktop](https://github.com/element-hq/element-desktop/)
|
||||
- [Element Web](https://github.com/element-hq/element-web/)
|
||||
- [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
|
||||
- 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/element-hq/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.
|
||||
- You must be part of the 2 Releasers GitHub groups:
|
||||
- <https://github.com/orgs/element-hq/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>
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ For security, you may wish to merge the security advisory private fork or apply
|
|||
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
|
||||
- [ ] The staging branch is prepared
|
||||
|
||||
# Releasing
|
||||
|
||||
|
|
@ -192,21 +192,21 @@ switched back to the version of the dependency from the master branch to not lea
|
|||
|
||||
### Matrix JS SDK
|
||||
|
||||
- [ ] Check the draft release which has been generated by [the automation](https://github.com/matrix-org/matrix-js-sdk/actions/workflows/release-drafter.yml)
|
||||
- [ ] Make any changes to the release notes in the draft release as are necessary - **Do not click publish, only save draft**
|
||||
- [ ] 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.
|
||||
- [ ] Check the draft release which has been generated by [the automation](https://github.com/matrix-org/matrix-js-sdk/actions/workflows/release-drafter.yml)
|
||||
- [ ] Make any changes to the release notes in the draft release as are necessary - **Do not click publish, only save draft**
|
||||
- [ ] 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.
|
||||
|
||||
### Element Web
|
||||
|
||||
- [ ] Check the draft release which has been generated by [the automation](https://github.com/element-hq/element-web/actions/workflows/release-drafter.yml)
|
||||
- [ ] Make any changes to the release notes in the draft release as are necessary - **Do not click publish, only save draft**
|
||||
- [ ] Kick off a release using [the automation](https://github.com/element-hq/element-web/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.
|
||||
- [ ] Check the draft release which has been generated by [the automation](https://github.com/element-hq/element-web/actions/workflows/release-drafter.yml)
|
||||
- [ ] Make any changes to the release notes in the draft release as are necessary - **Do not click publish, only save draft**
|
||||
- [ ] Kick off a release using [the automation](https://github.com/element-hq/element-web/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.
|
||||
|
||||
### Element Desktop
|
||||
|
||||
- [ ] Check the draft release which has been generated by [the automation](https://github.com/element-hq/element-desktop/actions/workflows/release-drafter.yml)
|
||||
- [ ] Make any changes to the release notes in the draft release as are necessary - **Do not click publish, only save draft**
|
||||
- [ ] Kick off a release using [the automation](https://github.com/element-hq/element-desktop/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.
|
||||
- [ ] Check the draft release which has been generated by [the automation](https://github.com/element-hq/element-desktop/actions/workflows/release-drafter.yml)
|
||||
- [ ] Make any changes to the release notes in the draft release as are necessary - **Do not click publish, only save draft**
|
||||
- [ ] Kick off a release using [the automation](https://github.com/element-hq/element-desktop/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.
|
||||
|
||||
# Deploying
|
||||
|
||||
|
|
@ -214,23 +214,23 @@ 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
|
||||
- [ ] 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
|
||||
- [ ] 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/element-hq/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)
|
||||
- [ ] Update topics using [the automation](https://github.com/element-hq/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>
|
||||
|
||||
|
|
@ -246,15 +246,15 @@ With wording like:
|
|||
|
||||
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-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 [element-web Renovate dashboard](https://github.com/element-hq/element-web/issues/22941) and click the checkbox to create/update its PRs.
|
||||
- [ ] Go to the [element-web Renovate dashboard](https://github.com/element-hq/element-web/issues/22941) and click the checkbox to create/update its PRs.
|
||||
|
||||
- [ ] Go to the [element-desktop Renovate dashboard](https://github.com/element-hq/element-desktop/issues/465) and click the checkbox to create/update its PRs.
|
||||
- [ ] Go to the [element-desktop Renovate dashboard](https://github.com/element-hq/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#).
|
||||
- [ ] 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/element-hq/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.
|
||||
- [ ] Archive done column on the [team board](https://github.com/orgs/element-hq/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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -6,11 +6,11 @@ It's so complicated it needs its own README.
|
|||
|
||||
Legend:
|
||||
|
||||
- Orange = External event.
|
||||
- Purple = Deterministic flow.
|
||||
- Green = Algorithm definition.
|
||||
- Red = Exit condition/point.
|
||||
- Blue = Process definition.
|
||||
- Orange = External event.
|
||||
- Purple = Deterministic flow.
|
||||
- Green = Algorithm definition.
|
||||
- Red = Exit condition/point.
|
||||
- Blue = Process definition.
|
||||
|
||||
## Algorithms involved
|
||||
|
||||
|
|
@ -68,14 +68,14 @@ simply get the manual sorting algorithm applied to them with no further involvem
|
|||
algorithm. There are 4 categories: Red, Grey, Bold, and Idle. Each has their own definition based off
|
||||
relative (perceived) importance to the user:
|
||||
|
||||
- **Red**: The room has unread mentions waiting for the user.
|
||||
- **Grey**: The room has unread notifications waiting for the user. Notifications are simply unread
|
||||
messages which cause a push notification or badge count. Typically, this is the default as rooms get
|
||||
set to 'All Messages'.
|
||||
- **Bold**: The room has unread messages waiting for the user. Essentially this is a grey room without
|
||||
a badge/notification count (or 'Mentions Only'/'Muted').
|
||||
- **Idle**: No useful (see definition of useful above) activity has occurred in the room since the user
|
||||
last read it.
|
||||
- **Red**: The room has unread mentions waiting for the user.
|
||||
- **Grey**: The room has unread notifications waiting for the user. Notifications are simply unread
|
||||
messages which cause a push notification or badge count. Typically, this is the default as rooms get
|
||||
set to 'All Messages'.
|
||||
- **Bold**: The room has unread messages waiting for the user. Essentially this is a grey room without
|
||||
a badge/notification count (or 'Mentions Only'/'Muted').
|
||||
- **Idle**: No useful (see definition of useful above) activity has occurred in the room since the user
|
||||
last read it.
|
||||
|
||||
Conveniently, each tag gets ordered by those categories as presented: red rooms appear above grey, grey
|
||||
above bold, etc.
|
||||
|
|
|
|||
|
|
@ -10,13 +10,13 @@ of dealing with the different levels and exposes easy to use getters and setters
|
|||
Granular Settings rely on a series of known levels in order to use the correct value for the scenario. These levels, in
|
||||
order of priority, are:
|
||||
|
||||
- `device` - The current user's device
|
||||
- `room-device` - The current user's device, but only when in a specific room
|
||||
- `room-account` - The current user's account, but only when in a specific room
|
||||
- `account` - The current user's account
|
||||
- `room` - A specific room (setting for all members of the room)
|
||||
- `config` - Values are defined by the `setting_defaults` key (usually) in `config.json`
|
||||
- `default` - The hardcoded default for the settings
|
||||
- `device` - The current user's device
|
||||
- `room-device` - The current user's device, but only when in a specific room
|
||||
- `room-account` - The current user's account, but only when in a specific room
|
||||
- `account` - The current user's account
|
||||
- `room` - A specific room (setting for all members of the room)
|
||||
- `config` - Values are defined by the `setting_defaults` key (usually) in `config.json`
|
||||
- `default` - The hardcoded default for the settings
|
||||
|
||||
Individual settings may control which levels are appropriate for them as part of the defaults. This is often to ensure
|
||||
that room administrators cannot force account-only settings upon participants.
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
## Requirements
|
||||
|
||||
- A working [Development Setup](../README.md#setting-up-a-dev-environment)
|
||||
- Latest LTS version of Node.js installed
|
||||
- Be able to understand English
|
||||
- A working [Development Setup](../README.md#setting-up-a-dev-environment)
|
||||
- Latest LTS version of Node.js installed
|
||||
- Be able to understand English
|
||||
|
||||
## Translating strings vs. marking strings for translation
|
||||
|
||||
|
|
@ -65,17 +65,17 @@ There you can also require all translations to be redone if the meaning of the s
|
|||
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 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> })`.
|
||||
- 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> })`.
|
||||
|
||||
## 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 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)
|
||||
- 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 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)
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
## 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
|
||||
|
||||
## Join #element-translations:matrix.org
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue