diff --git a/doc/administration/docs_self_host.md b/doc/administration/docs_self_host.md
index 776224de44aa7d4de8d77e7ba93db48d323e1bed..9021a795523c6565b45286e5cc3a2f2979d0d1d1 100644
--- a/doc/administration/docs_self_host.md
+++ b/doc/administration/docs_self_host.md
@@ -261,7 +261,7 @@ To upgrade to a later version [using your own web-server](#self-host-the-product
If you self-host the product documentation:
-- The version dropdown displays additional versions that don't exist. Selecting
+- The version dropdown list displays additional versions that don't exist. Selecting
these versions displays a `404 Not Found` page.
- The search displays results from `docs.gitlab.com` and not the local site.
- By default, the landing page redirects to the
diff --git a/doc/administration/logs/tracing_correlation_id.md b/doc/administration/logs/tracing_correlation_id.md
index 6fb98dd354b6a71f101b458213585d02cd5c2e8b..f651455a0883d5764628d935476e082c49a8ae1c 100644
--- a/doc/administration/logs/tracing_correlation_id.md
+++ b/doc/administration/logs/tracing_correlation_id.md
@@ -187,7 +187,7 @@ You can then view the database details for this request:
-1. A new request is inserted into the `Request Selector` dropdown on the right-hand side of the Performance Bar. Select the new request to view the metrics of the API request:
+1. A new request is inserted into the `Request Selector` dropdown list on the right-hand side of the Performance Bar. Select the new request to view the metrics of the API request:
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index 567c71878dc87efdcc5c1109330776e57f475211..56583deca89975a0bb936f1ce34eaf3e9b0105ee 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -353,7 +353,7 @@ To add a Prometheus dashboard for a single server GitLab setup:
1. Create a new data source in Grafana.
1. Name your data source (such as GitLab).
-1. Select `Prometheus` in the type dropdown box.
+1. Select `Prometheus` in the type dropdown list.
1. Add your Prometheus listen address as the URL, and set access to `Browser`.
1. Set the HTTP method to `GET`.
1. Save and test your configuration to verify that it works.
diff --git a/doc/api/settings.md b/doc/api/settings.md
index 2054b4e9eea0fefeaa49f6280145bd5a2dfab811..3d8d02b84297f85ab3425d0fcf36c884cb50c858 100644
--- a/doc/api/settings.md
+++ b/doc/api/settings.md
@@ -354,7 +354,7 @@ listed in the descriptions of the relevant settings.
| `gravatar_enabled` | boolean | no | Enable Gravatar. |
| `hashed_storage_enabled` | boolean | no | Create new projects using hashed storage paths: Enable immutable, hash-based paths and repository names to store repositories on disk. This prevents repositories from having to be moved or renamed when the Project URL changes and may improve disk I/O performance. (Always enabled in GitLab versions 13.0 and later, configuration is scheduled for removal in 14.0) |
| `help_page_hide_commercial_content` | boolean | no | Hide marketing-related entries from help. |
-| `help_page_support_url` | string | no | Alternate support URL for help page and help dropdown. |
+| `help_page_support_url` | string | no | Alternate support URL for help page and help dropdown list. |
| `help_page_text` | string | no | Custom text displayed on the help page. |
| `help_text` **(PREMIUM)** | string | no | GitLab server administrator information. |
| `hide_third_party_offers` | boolean | no | Do not display offers from third parties in GitLab. |
diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md
index c19e4e5a1402c1614053bf2d0d60486afbcb5a6e..15c4f0b1349dae0f4c1e704ed5e7f0545e405be8 100644
--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@@ -133,7 +133,7 @@ they have the following privileges:
Users granted access to a protected environment, but not push or merge access
to the branch deployed to it, are only granted access to deploy the environment.
[Invited groups](../../user/project/members/share_project_with_groups.md#share-a-project-with-a-group-of-users) added
-to the project with [Reporter role](../../user/permissions.md#project-members-permissions), appear in the dropdown menu for deployment-only access.
+to the project with [Reporter role](../../user/permissions.md#project-members-permissions), appear in the dropdown list for deployment-only access.
To add deployment-only access:
@@ -146,7 +146,7 @@ To add deployment-only access:
Maintainers can:
- Update existing protected environments at any time by changing the access in the
- **Allowed to Deploy** dropdown menu.
+ **Allowed to Deploy** dropdown list.
- Unprotect a protected environment by clicking the **Unprotect** button for that environment.
After an environment is unprotected, all access entries are deleted and must
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index cfd0855e1a7647749fa683ae2068429b47a2b4c9..300de610aa7b0254809719ede98ae5dcb9a329b8 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -211,7 +211,7 @@ For advanced CI/CD teams, project templates can enable the reuse of pipeline con
as well as encourage inner sourcing.
In self-managed GitLab instances, you can build an [Instance Template Repository](../../user/admin_area/settings/instance_template_repository.md).
-Development teams across the whole organization can select templates from a dropdown menu.
+Development teams across the whole organization can select templates from a dropdown list.
A group maintainer or a group owner is able to set a group to use as the source for the
[custom project templates](../../user/admin_area/custom_project_templates.md), which can
be used by all projects in the group. An instance administrator can set a group as
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 9447dd59a12dbdf640d449ae6f43869a7ce3bc26..d715500435951d11fb662596dca275f1e420ed09 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -329,7 +329,7 @@ you can view a graph or download a CSV file with this data.
1. On the top bar, select **Main menu > Projects** and find your project.
1. On the left sidebar, select **Analytics > Repository**.
-The historic data for each job is listed in the dropdown above the graph.
+The historic data for each job is listed in the dropdown list above the graph.
To view a CSV file of the data, select **Download raw data (`.csv`)**.
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index 93862f51cc82783cf16d83630d0aea399339e2aa..7dc3ae0a80b15cf6ae1266bb29c0e5761a99c033 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -114,7 +114,7 @@ making it both concise and descriptive, err on the side of descriptive.
- **Bad:** Go to a project order.
- **Good:** Show a user's starred projects at the top of the "Go to project"
- dropdown.
+ dropdown list.
The first example provides no context of where the change was made, or why, or
how it benefits the user.
@@ -126,9 +126,9 @@ how it benefits the user.
Again, the first example is too vague and provides no context.
- **Bad:** Fixes and Improves CSS and HTML problems in mini pipeline graph and
- builds dropdown.
+ builds dropdown list.
- **Good:** Fix tooltips and hover states in mini pipeline graph and builds
- dropdown.
+ dropdown list.
The first example is too focused on implementation details. The user doesn't
care that we changed CSS and HTML, they care about the _end result_ of those
diff --git a/doc/development/cicd/templates.md b/doc/development/cicd/templates.md
index 4e0baf33ead265c31ab2d3c590a30bec32a7752b..85ac58e749dca46ea3cd45c5847893f4638db40c 100644
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@@ -391,7 +391,7 @@ This is useful information for reviewers to make sure the template is safe to be
### Make sure the new template can be selected in UI
Templates located under some directories are also [selectable in the **New file** UI](#template-directories).
-When you add a template into one of those directories, make sure that it correctly appears in the dropdown:
+When you add a template into one of those directories, make sure that it correctly appears in the dropdown list:
diff --git a/doc/development/database/pagination_guidelines.md b/doc/development/database/pagination_guidelines.md
index edf15f0328723e5b4ff392ff4342d02c8f175507..d1763f522d5ca375cf3c6fa0cdbae66c49b15cb8 100644
--- a/doc/development/database/pagination_guidelines.md
+++ b/doc/development/database/pagination_guidelines.md
@@ -50,9 +50,9 @@ When we list records on the page we often provide additional filters and differe
For the MVC version, consider the following:
- Reduce the number of sort options to the minimum.
-- Reduce the number of filters (dropdown, search bar) to the minimum.
+- Reduce the number of filters (dropdown list, search bar) to the minimum.
-To make sorting and pagination efficient, for each sort option we need at least two database indexes (ascending, descending order). If we add filter options (by state or by author), we might need more indexes to maintain good performance. Note that indexes are not free, they can significantly affect the `UPDATE` query timings.
+To make sorting and pagination efficient, for each sort option we need at least two database indexes (ascending, descending order). If we add filter options (by state or by author), we might need more indexes to maintain good performance. Indexes are not free, they can significantly affect the `UPDATE` query timings.
It's not possible to make all filter and sort combinations performant, so we should try optimizing the performance by usage patterns.
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 1cf4c1d60b1854dc479f61bb435fea2ed0bcd1fb..9ed3e551ff25ea3299e331f4bdb2a2dbea15dc2c 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -330,7 +330,7 @@ Along with creating local data, we can also extend existing GraphQL types with `
##### Mocking API response with local Apollo cache
-Using local Apollo Cache is helpful when we have a need to mock some GraphQL API responses, queries, or mutations locally (such as when they're still not added to our actual API).
+Using local Apollo Cache is helpful when we have a reason to mock some GraphQL API responses, queries, or mutations locally (such as when they're still not added to our actual API).
For example, we have a [fragment](#fragments) on `DesignVersion` used in our queries:
@@ -341,7 +341,7 @@ fragment VersionListItem on DesignVersion {
}
```
-We also need to fetch the version author and the `created at` property to display in the versions dropdown. But, these changes are still not implemented in our API. We can change the existing fragment to get a mocked response for these new fields:
+We also must fetch the version author and the `created at` property to display in the versions dropdown list. But, these changes are still not implemented in our API. We can change the existing fragment to get a mocked response for these new fields:
```javascript
fragment VersionListItem on DesignVersion {
@@ -627,7 +627,7 @@ GraphQL entities are not yet part of the schema, or if they are feature-flagged
### Manually triggering queries
Queries on a component's `apollo` property are made automatically when the component is created.
-Some components instead want the network request made on-demand, for example a dropdown with lazy-loaded items.
+Some components instead want the network request made on-demand, for example a dropdown list with lazy-loaded items.
There are two ways to do this:
diff --git a/doc/development/i18n/merging_translations.md b/doc/development/i18n/merging_translations.md
index 0bc7e3ed925c459bb99aae66be848a301b1d15c9..2a086c796c97e833178583c8547e65fa5c96e9a1 100644
--- a/doc/development/i18n/merging_translations.md
+++ b/doc/development/i18n/merging_translations.md
@@ -79,7 +79,7 @@ recreate it with the following steps:
## Manually update the translation levels
There's no automated way to pull the translation levels from Crowdin, to display
-this information in the language selection dropdown. Therefore, the translation
+this information in the language selection dropdown list. Therefore, the translation
levels are hard-coded in the `TRANSLATION_LEVELS` constant in [`i18n.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/i18n.rb),
and must be regularly updated.
diff --git a/doc/development/refactoring_guide/index.md b/doc/development/refactoring_guide/index.md
index 44beb0623a9a3cc5822fa531dad0bf116dba1749..5dd505ff5c6e1b50f3be0234ef1da518a5554043 100644
--- a/doc/development/refactoring_guide/index.md
+++ b/doc/development/refactoring_guide/index.md
@@ -77,7 +77,7 @@ expect(cleanForSnapshot(wrapper.element)).toMatchSnapshot();
- [Pinning test in a Haml to Vue refactor](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27691#pinning-tests)
- [Pinning test in isolating a bug](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/32198#note_212736225)
-- [Pinning test in refactoring dropdown](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28173)
+- [Pinning test in refactoring dropdown list](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28173)
- [Pinning test in refactoring vulnerability_details.vue](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25830/commits)
- [Pinning test in refactoring notes_award_list.vue](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29528#pinning-test)
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Video of pair programming session on pinning tests](https://youtu.be/LrakPcspBK4)
diff --git a/doc/development/snowplow/index.md b/doc/development/snowplow/index.md
index eba8ceca3ac2f10b4f078cab4bc92c4de02ed557..7327f18fcaf0710448de7228579a615668945ced 100644
--- a/doc/development/snowplow/index.md
+++ b/doc/development/snowplow/index.md
@@ -90,7 +90,7 @@ Each click event provides attributes that describe the event.
| Attribute | Type | Required | Description |
| --------- | ------- | -------- | ----------- |
| category | text | true | The page or backend section of the application. Unless infeasible, use the Rails page attribute by default in the frontend, and namespace + class name on the backend, for example, `Notes::CreateService`. |
-| action | text | true | The action the user takes, or aspect that's being instrumented. The first word must describe the action or aspect. For example, clicks must be `click`, activations must be `activate`, creations must be `create`. Use underscores to describe what was acted on. For example, activating a form field is `activate_form_input`, an interface action like clicking on a dropdown is `click_dropdown`, a behavior like creating a project record from the backend is `create_project`. |
+| action | text | true | The action the user takes, or aspect that's being instrumented. The first word must describe the action or aspect. For example, clicks must be `click`, activations must be `activate`, creations must be `create`. Use underscores to describe what was acted on. For example, activating a form field is `activate_form_input`, an interface action like clicking on a dropdown list is `click_dropdown`, a behavior like creating a project record from the backend is `create_project`. |
| label | text | false | The specific element or object to act on. This can be one of the following: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown in the top bar; or the name or title attribute of a record being created. For Service Ping metrics adapted to Snowplow events, this should be the full metric [key path](../service_ping/metrics_dictionary.md#metric-key_path) taken from its definition file. |
| property | text | false | Any additional property of the element, or object being acted on. For Service Ping metrics adapted to Snowplow events, this should be additional information or context that can help analyze the event. For example, in the case of `usage_activity_by_stage_monthly.create.merge_requests_users`, there are four different possible merge request actions: "create", "merge", "comment", and "close". Each of these would be a possible property value. |
| value | decimal | false | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility. |
diff --git a/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md b/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
index 170bf723a8d4e9f3b72990a12bb911d32f320dca..fb5d5bbe3791ddf1e5289d0b33dae5a0dcc3a26d 100644
--- a/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
+++ b/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
@@ -54,8 +54,8 @@ description, note the following:
precision is 2. In some extremely low panels, you can see `0.00`, even though there is still some
real traffic.
-To inspect the raw data of the panel for further calculation, select **Inspect** from the dropdown
-list of a panel. Queries, raw data, and panel JSON structure are available.
+To inspect the raw data of the panel for further calculation, select **Inspect** from the dropdown list of a panel.
+Queries, raw data, and panel JSON structure are available.
Read more at [Grafana panel inspection](http://grafana.com/docs/grafana/next/panels/query-a-data-source/).
All the dashboards are powered by [Grafana](https://grafana.com/), a frontend for displaying metrics.
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 973ec0555f682e768af89458b0e978b3076c2f5d..d86d1c3c7b49ff3171d1fb1d6dd01e78c2fdae16 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -101,7 +101,7 @@ the GitLab handbook information for the [shared 1Password account](https://about
1. [Filter Workloads by your Review App slug](https://console.cloud.google.com/kubernetes/workload?project=gitlab-review-apps). For example, `review-qa-raise-e-12chm0`.
1. Find and open the `toolbox` Deployment. For example, `review-qa-raise-e-12chm0-toolbox`.
1. Select the Pod in the "Managed pods" section. For example, `review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz`.
-1. Select the `KUBECTL` dropdown, then `Exec` -> `toolbox`.
+1. Select the `KUBECTL` dropdown list, then `Exec` -> `toolbox`.
1. Replace `-c toolbox -- ls` with `-it -- gitlab-rails console` from the
default command or
- Run `kubectl exec --namespace review-qa-raise-e-12chm0 review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz -it -- gitlab-rails console` and
diff --git a/doc/development/work_items_widgets.md b/doc/development/work_items_widgets.md
index 67ffdd14b6aa39e94b4770df3fb0e04172578224..89602d969e6334622a76660a0a5ff57f96b0ee18 100644
--- a/doc/development/work_items_widgets.md
+++ b/doc/development/work_items_widgets.md
@@ -88,7 +88,7 @@ To maximize component reusability, widgets should be field wrappers owning the
work item query and mutation of the attribute it's responsible for.
A field component is a generic and simple component. It has no knowledge of the
-attribute or work item details, such as input field, date selector, or dropdown.
+attribute or work item details, such as input field, date selector, or dropdown list.
Widgets must be configurable to support various use cases, depending on work items.
When building widgets, use slots to provide extra context while minimizing
@@ -96,18 +96,18 @@ the use of props and injected attributes.
### Examples
-We have a [dropdown field component](https://gitlab.com/gitlab-org/gitlab/-/blob/eea9ad536fa2d28ee6c09ed7d9207f803142eed7/app/assets/javascripts/vue_shared/components/dropdown/dropdown_widget/dropdown_widget.vue)
+We have a [dropdown list component](https://gitlab.com/gitlab-org/gitlab/-/blob/eea9ad536fa2d28ee6c09ed7d9207f803142eed7/app/assets/javascripts/vue_shared/components/dropdown/dropdown_widget/dropdown_widget.vue)
for use as reference.
-Any work item widget can wrap the dropdown component. The widget has knowledge of
+Any work item widget can wrap the dropdown list. The widget has knowledge of
the attribute it mutates, and owns the mutation for it. Multiple widgets can use
the same field component. For example:
- Title and description widgets use the input field component.
- Start and end date use the date selector component.
-- Labels, milestones, and assignees selectors use the dropdown component.
+- Labels, milestones, and assignees selectors use the dropdown list.
-Some frontend widgets already use the dropdown component. Use them as a reference
+Some frontend widgets already use the dropdown list. Use them as a reference
for work items widgets development:
- `ee/app/assets/javascripts/boards/components/assignee_select.vue`