This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

Allow for reuse of the custom metric form fields

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

Added the feature to download LFS objects with pull mirrors. The
service used to download the LFS objects is the same one used for
project import.

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

Suppose you have this configuration:

1. Subgroup `hello/world`
2. Subgroup `hello/mergers`.
3. Project `hello/world/my-project` has invited group `hello/world` to
access protected branches.
4. The rule allows the group to merge but no one can push.
5. User `newuser` has Owner access to the parent group `hello`.

Previously, there was no way for the user `newuser` to be added to the
`hello/mergers` group since the validation only allowed a user to be
added at a higher access level.

Since membership in a subgroup confers certain access rights, such as
being able to merge or push code to protected branches, we have to
loosen the validation and allow someone to be added at an equal level
granted by the parent group.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/11323

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This allows uploading designs through GraphQL.

The mutation requires these arguments:

- `fullPath`: The path in which we can find the issue for creating
  designs
- `iid`: The iid of the issue in which to upload designs
- `files`: An array of files. We expect these to be in the format
  used by apollo-upload-client[0] which uses this spec[1] for
  multipart fileupload.

The middleware used for handling the multipart upload an translating
the variables is apollo_upload_server[2]

When a file is uploaded, the basename is used for creating a design,
when a design for the specified issue did not exist for the filename,
a new one is created. Otherwise the existing one is used.

When uploading a new file, a new version is created an linked to the
design being updated or created.

The files are stored in a repository that lives next to the project
repository with the path `@hashed/[hash]/[to]/[repo].design.git. The
files are not yet stored in LFS, but they should be.

0: https://github.com/jaydenseric/apollo-upload-client
1: https://github.com/jaydenseric/graphql-multipart-request-spec
2: https://github.com/jetruby/apollo_upload_server-ruby

Also regenerate gitlab.pot

This reverts commit 0c4a25f3, reversing
changes made to 6513028e.

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets the Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This is one of many MRs opened in order to improve the overall
internationalisation of the GitLab codebase.

This commit only targets Vanilla JS files.

i18n documentation
https://docs.gitlab.com/ee/development/i18n/externalization.html

This allows uploading designs through GraphQL.

The mutation requires these arguments:

- `fullPath`: The path in which we can find the issue for creating
  designs
- `iid`: The iid of the issue in which to upload designs
- `files`: An array of files. We expect these to be in the format
  used by apollo-upload-client[0] which uses this spec[1] for
  multipart fileupload.

The middleware used for handling the multipart upload an translating
the variables is apollo_upload_server[2]

When a file is uploaded, the basename is used for creating a design,
when a design for the specified issue did not exist for the filename,
a new one is created. Otherwise the existing one is used.

When uploading a new file, a new version is created an linked to the
design being updated or created.

The files are stored in a repository that lives next to the project
repository with the path `@hashed/[hash]/[to]/[repo].design.git. The
files are not yet stored in LFS, but they should be.

0: https://github.com/jaydenseric/apollo-upload-client
1: https://github.com/jaydenseric/graphql-multipart-request-spec
2: https://github.com/jetruby/apollo_upload_server-ruby

Store Let's Encrypt account email in application settings
Also add explicit terms of service consent

The environments dashboard exists to show a list of all environments in
a project, as well as their status, any available alerts, and the status
of the last pipeline ran for that environment.

This starts us down the path of unifying the data on the modal and
allows us to start showing dismissal data in the same way across the two
different uses of the security reports modal