Merge branch 'eread/ctrt-subgroups-topic' into 'master'

Update topic for CTRT principles

See merge request gitlab-org/gitlab!81120

app/views/projects/pages/_ssl_limitations_warning.html.haml

@@ -2,6 +2,6 @@
   = sprite_icon("warning-solid", css_class: "gl-text-orange-600")
   %strong= _("Warning:")
   - pages_host = Gitlab.config.pages.host
-  - docs_link_start = "<a href='#{help_page_path('user/project/pages/introduction', anchor: 'limitations')}' target='_blank' rel='noopener noreferrer'>".html_safe
+  - docs_link_start = "<a href='#{help_page_path('user/project/pages/introduction', anchor: 'subdomains-of-subdomains')}' target='_blank' rel='noopener noreferrer'>".html_safe
   - link_end = '</a>'.html_safe
-  = s_("GitLabPages|When using Pages under the general domain of a GitLab instance (%{pages_host}), you cannot use HTTPS with sub-subdomains. This means that if your username/groupname contains a dot it will not work. This is a limitation of the HTTP Over TLS protocol. HTTP pages will continue to work provided you don't redirect HTTP to HTTPS. %{docs_link_start}Learn more.%{link_end}").html_safe % { pages_host: pages_host, docs_link_start: docs_link_start, link_end: link_end }
+  = s_("GitLabPages|When using Pages under the general domain of a GitLab instance (%{pages_host}), you cannot use HTTPS with subdomains of subdomains. If your namespace or groupname contains a dot, it does not work. This is a limitation of the HTTP Over TLS protocol. HTTP pages work if you don't redirect HTTP to HTTPS. %{docs_link_start}Learn more.%{link_end}").html_safe % { pages_host: pages_host, docs_link_start: docs_link_start, link_end: link_end }

doc/administration/get_started.md

@@ -39,8 +39,8 @@ Get started:
 - Create a [project](../user/project/working_with_projects.md#create-a-project).
 - Create a [group](../user/group/index.md#create-a-group).
 - [Add members](../user/group/index.md#add-users-to-a-group) to the group.
-- Create a [subgroup](../user/group/subgroups/index.md#creating-a-subgroup).
-- [Add members](../user/group/subgroups/index.md#membership) to the subgroup.
+- Create a [subgroup](../user/group/subgroups/index.md#create-a-subgroup).
+- [Add members](../user/group/subgroups/index.md#subgroup-membership) to the subgroup.
 - Enable [external authorization control](../user/admin_area/settings/external_authorization.md#configuration).
 
 **More resources**
@@ -49,7 +49,7 @@ Get started:
 - Sync group memberships [by using LDAP](../administration/auth/ldap/ldap_synchronization.md#group-sync).
 - Manage user access with inherited permissions. Use up to 20 levels of subgroups to organize both teams and projects.
   - Learn more about [inherited permissions](../user/project/members/index.md#inherited-membership).
-  - View [nested category examples](../user/group/subgroups/index.md#overview).
+  - View an [example](../user/group/subgroups/index.md).
 
 ## Import projects
 

doc/api/groups.md

@@ -796,7 +796,7 @@ Parameters:
 | `two_factor_grace_period`                               | integer | no       | Time before Two-factor authentication is enforced (in hours). |
 | `project_creation_level`                                | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (users with the Maintainer role), or `developer` (users with the Developer or Maintainer role). |
 | `auto_devops_enabled`                                   | boolean | no       | Default to Auto DevOps pipeline for all projects within this group. |
-| `subgroup_creation_level`                               | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#creating-a-subgroup). Can be `owner` (Owners), or `maintainer` (users with the Maintainer role). |
+| `subgroup_creation_level`                               | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#create-a-subgroup). Can be `owner` (Owners), or `maintainer` (users with the Maintainer role). |
 | `emails_disabled`                                       | boolean | no       | Disable email notifications |
 | `avatar`                                                | mixed   | no       | Image file for avatar of the group. [Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/36681) |
 | `mentions_disabled`                                     | boolean | no       | Disable the capability of a group from getting mentioned |
@@ -859,7 +859,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
 Transfer a group to a new parent group or turn a subgroup to a top-level group. Available to administrators and users:
 
 - With the Owner role for the group to transfer.
-- With permission to [create a subgroup](../user/group/subgroups/index.md#creating-a-subgroup) in the new parent group if transferring a group.
+- With permission to [create a subgroup](../user/group/subgroups/index.md#create-a-subgroup) in the new parent group if transferring a group.
 - With [permission to create a top-level group](../administration/user_settings.md#prevent-users-from-creating-top-level-groups) if turning a subgroup into a top-level group.
 
 ```plaintext
@@ -899,7 +899,7 @@ PUT /groups/:id
 | `two_factor_grace_period`                               | integer | no       | Time before Two-factor authentication is enforced (in hours). |
 | `project_creation_level`                                | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (users with the Maintainer role), or `developer` (users with the Developer or Maintainer role). |
 | `auto_devops_enabled`                                   | boolean | no       | Default to Auto DevOps pipeline for all projects within this group. |
-| `subgroup_creation_level`                               | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#creating-a-subgroup). Can be `owner` (Owners), or `maintainer` (users with the Maintainer role). |
+| `subgroup_creation_level`                               | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#create-a-subgroup). Can be `owner` (Owners), or `maintainer` (users with the Maintainer role). |
 | `emails_disabled`                                       | boolean | no       | Disable email notifications |
 | `avatar`                                                | mixed   | no       | Image file for avatar of the group. [Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/36681) |
 | `mentions_disabled`                                     | boolean | no       | Disable the capability of a group from getting mentioned |

doc/user/admin_area/index.md

@@ -224,6 +224,17 @@ You must be an administrator to manually add emails to users:
 
 The [Cohorts](user_cohorts.md) tab displays the monthly cohorts of new users and their activities over time.
 
+### Prevent a user from creating groups
+
+By default, users can create groups. To prevent a user from creating groups:
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Overview > Users** (`/admin/users`).
+1. Locate the user and select them.
+1. Select **Edit**.
+1. Clear the **Can create group** checkbox.
+1. Select **Save changes**.
+
 ### Administering Groups
 
 You can administer all groups in the GitLab instance from the Admin Area's Groups page.

doc/user/discussions/index.md

@@ -36,10 +36,9 @@ Each object can have as many as 5,000 comments.
 
 ## Mentions
 
-You can mention a user or a group present in your GitLab instance with `@username` or
-`@groupname`. All mentioned users are notified with to-do items and emails.
-Users can change this setting for themselves in the
-[notification settings](../profile/notifications.md).
+You can mention a user or a group (including [subgroups](../group/subgroups/index.md#mention-subgroups)) in your GitLab
+instance with `@username` or `@groupname`. All mentioned users are notified with to-do items and emails.
+Users can change this setting for themselves in the [notification settings](../profile/notifications.md).
 
 You can quickly see which comments involve you, because
 mentions for yourself (the user currently signed in) are highlighted

doc/user/group/subgroups/index.md

@@ -2,118 +2,92 @@
 stage: Manage
 group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference, howto, concepts
 ---
 
 # Subgroups **(FREE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/2772) in GitLab 9.0.
 
-GitLab supports up to 20 levels of subgroups, also known as nested groups or hierarchical groups.
-
-By using subgroups you can do the following:
-
-- **Separate internal / external organizations.** Since every group
-  can have its own visibility level ([public, internal, or private](../../../development/permissions.md#general-permissions)),
-  you're able to host groups for different purposes under the same umbrella.
-- **Organize large projects.** For large projects, subgroups makes it
-  potentially easier to separate permissions on parts of the source code.
-- **Make it easier to manage people and control visibility.** Give people
-  different [permissions](../../permissions.md#group-members-permissions) depending on their group [membership](#membership).
-
-For more information on allowed permissions in groups and projects, see
-[visibility levels](../../../development/permissions.md#general-permissions).
-
-## Overview
-
-A group can have many subgroups inside it, and at the same time a group can have
-only one immediate parent group. It resembles a directory behavior or a nested items list:
-
-- Group 1
-  - Group 1.1
-  - Group 1.2
-    - Group 1.2.1
-    - Group 1.2.2
-      - Group 1.2.2.1
-
-In a real world example, imagine maintaining a GNU/Linux distribution with the
-first group being the name of the distribution, and subsequent groups split as follows:
-
-- Organization Group - GNU/Linux distro
-  - Category Subgroup - Packages
-    - (project) Package01
-    - (project) Package02
-  - Category Subgroup - Software
-    - (project) Core
-    - (project) CLI
-    - (project) Android app
-    - (project) iOS app
-  - Category Subgroup - Infra tools
-    - (project) Ansible playbooks
-
-Another example of GitLab as a company would be the following:
-
-- Organization Group - GitLab
-  - Category Subgroup - Marketing
-    - (project) Design
-    - (project) General
-  - Category Subgroup - Software
-    - (project) GitLab CE
-    - (project) GitLab EE
-    - (project) Omnibus GitLab
-    - (project) GitLab Runner
-    - (project) GitLab Pages daemon
-  - Category Subgroup - Infra tools
-    - (project) Chef cookbooks
-  - Category Subgroup - Executive team
-
-When performing actions such as transferring or importing a project between
-subgroups, the behavior is the same as when performing these actions at the
-`group/project` level.
-
-## Creating a subgroup
-
-Users can create subgroups if they are explicitly added as an Owner (or
-Maintainer, if that setting is enabled) to an immediate parent group, even if group
-creation is disabled by an administrator in their settings.
+You can organize GitLab [groups](../index.md) into subgroups. You can use subgroups to:
+
+- Separate internal and external organizations. Because every subgroup can have its own
+  [visibility level](../../../development/permissions.md#general-permissions), you can host groups for different
+  purposes under the same parent group.
+- Organize large projects. You can use subgroups to give different access to parts of
+  the source code.
+- Manage people and control visibility. Give a user a different
+  [role](../../permissions.md#group-members-permissions) for each group they're [a member of](#subgroup-membership).
+
+Subgroups can:
+
+- Belong to one immediate parent group.
+- Have many subgroups.
+- Be nested up to 20 levels.
+- Use [runners](../../../ci/runners/index.md) registered to parent groups:
+  - Secrets configured for the parent group are available to subgroup jobs.
+  - Users with the Maintainer role in projects that belong to subgroups can see the details of runners registered to
+    parent groups.
+
+For example:
+
+```mermaid
+graph TD
+    subgraph "Parent group"
+      subgraph "Subgroup A"
+        subgraph "Subgroup A1"
+          G["Project E"]
+        end
+        C["Project A"]
+        D["Project B"]
+        E["Project C"]
+      end
+      subgraph "Subgroup B"
+        F["Project D"]
+      end
+    end
+```
+
+## Create a subgroup
+
+Users with the at least the Maintainer role on a group can create subgroups immediately below the group, unless
+[configured otherwise](#change-who-can-create-subgroups). These users can create subgroups even if group creation is
+[disabled by an Administrator](../../admin_area/index.md#prevent-a-user-from-creating-groups) in the user's settings.
 
 To create a subgroup:
 
 1. On the top bar, select **Menu > Groups** and find the parent group.
 1. In the top right, select **New subgroup**.
 1. Select **Create group**.
-1. Fill in the fields. View a list of [reserved names](../../reserved_names.md)
-   that cannot be used as group names.
+1. Fill in the fields. View a list of [reserved names](../../reserved_names.md) that cannot be used as group names.
 1. Select **Create group**.
 
 ### Change who can create subgroups
 
-To create a subgroup you must either be an Owner or a Maintainer of the
-group, depending on the group's setting.
-
-By default:
+To create a subgroup, you must have at least the Maintainer role on the group, depending on the group's setting. By
+default:
 
-- In GitLab 12.2 or later, both Owners and Maintainers can create subgroups.
-- In GitLab 12.1 or earlier, only Owners can create subgroups.
+- In GitLab 12.2 or later, users with at least the Maintainer role can create subgroups.
+- In GitLab 12.1 or earlier, only users with the Owner role can create subgroups.
 
-You can change this setting:
+To change who can create subgroups on a group:
 
-- As group owner:
-  1. Select the group.
+- As a user with the Owner role on the group:
+  1. On the top bar, select **Menu > Groups** and find the group.
   1. On the left sidebar, select **Settings > General**.
   1. Expand **Permissions and group features**.
+  1. Select a role from the **Allowed to create subgroups** dropdown.
 - As an administrator:
   1. On the top bar, select **Menu > Admin**.
   1. On the left sidebar, select **Overview > Groups**.
   1. Select the group, and select **Edit**.
+  1. Select a role from the **Allowed to create subgroups** dropdown.
 
 For more information, view the [permissions table](../../permissions.md#group-members-permissions).
 
-## Membership
+## Subgroup membership
 
-When you add a member to a group, that member is also added to all subgroups.
-Permission level is inherited from the group's parent. This model allows access to
-subgroups if you have membership in one of its parents.
+When you add a member to a group, that member is also added to all subgroups. The user's permissions are inherited from
+the group's parent.
 
 Subgroup members can:
 
@@ -145,76 +119,59 @@ flowchart RL
   G-->|Group C shared with Subgroup A|E
 ```
 
-Jobs for pipelines in subgroups can use [runners](../../../ci/runners/index.md) registered to the parent group(s).
-This means secrets configured for the parent group are available to subgroup jobs.
+Group permissions for a member can be changed only by:
 
-In addition, maintainers of projects that belong to subgroups can see the details of runners registered to parent group(s).
+- Users with the Owner role on the group.
+- Changing the configuration of the group the member was added to.
 
-The group permissions for a member can be changed only by Owners, and only on
-the **Members** page of the group the member was added.
+### Determine membership inheritance
 
-You can tell if a member has inherited the permissions from a parent group by
-looking at the group's **Members** page.
+To see if a member has inherited the permissions from a parent group:
 
-![Group members page](img/group_members_v14_4.png)
-
-From the image above, we can deduce the following things:
+1. On the top bar, select **Menu > Groups** and find the group.
+1. Select **Group information > Members**.
 
-- There are 5 members that have access to the group `four`.
-- User 0 is a Reporter and has inherited their permissions from group `one`
-  which is above the hierarchy of group `four`.
-- User 1 is a Developer and has inherited their permissions from group
-  `one/two` which is above the hierarchy of group `four`.
-- User 2 is a Developer and has inherited their permissions from group
-  `one/two/three` which is above the hierarchy of group `four`.
-- For User 3 the **Source** column indicates **Direct member**, therefore they belong to
-  group `four`, the one we're inspecting.
-- Administrator is the Owner and member of **all** subgroups and for that reason,
-  as with User 3, the **Source** column indicates **Direct member**.
+Members list for an example subgroup _Four_:
 
-Members can be [filtered by inherited or direct membership](../index.md#filter-a-group).
-
-### Overriding the ancestor group membership
-
-NOTE:
-You must be an Owner of a group to be able to add members to it.
-
-NOTE:
-A user's permissions in a subgroup cannot be lower than in any of its ancestor groups.
-Therefore, you cannot reduce a user's permissions in a subgroup with respect to its ancestor groups.
+![Group members page](img/group_members_v14_4.png)
 
-To override a user's membership of an ancestor group (the first group they were
-added to), add the user to the new subgroup again with a higher set of permissions.
+In the screenshot above:
+
+- Five members have access to group _Four_.
+- User 0 has the Reporter role on group _Four_, and has inherited their permissions from group _One_:
+  - User 0 is a direct member of group _One_.
+  - Group _One_ is above group _Four_ in the hierarchy.
+- User 1 has the Developer role on group _Four_ and inherited their permissions from group _Two_:
+  - User 0 is a direct member of group _Two_, which is a subgroup of group _One_.
+  - Groups _One / Two_ are above group _Four_ in the hierarchy.
+- User 2 has the Developer role on group _Four_ and has inherited their permissions from group _Three_:
+  - User 0 is a direct member of group _Three_, which is a subgroup of group _Two_. Group _Two_ is a subgroup of group
+    _One_.
+  - Groups _One / Two / Three_ are above group _Four_ the hierarchy.
+- User 3 is a direct member of group _Four_. This means they get their Maintainer role directly from group _Four_.
+- Administrator has the Owner role on group _Four_ and is a member of all subgroups. For that reason, as with User 3,
+  the **Source** column indicates they are a direct member.
 
-For example, if User 1 was first added to group `one/two` with Developer
-permissions, then they inherit those permissions in every other subgroup
-of `one/two`. To give them the Maintainer role for group `one/two/three/four`,
-you would add them again in that group as Maintainer. Removing them from that group,
-the permissions fall back to those of the ancestor group.
+Members can be [filtered by inherited or direct membership](../index.md#filter-a-group).
 
-## Mentioning subgroups
+### Override ancestor group membership
 
-Mentioning groups (`@group`) in issues, commits and merge requests, would
-notify all members of that group. Now with subgroups, there is more granular
-support if you want to split your group's structure. Mentioning works as before
-and you can choose the group of people to be notified.
+Users with the Owner role on a subgroup can add members to it.
 
-![Mentioning subgroups](img/mention_subgroups.png)
+You can't give a user a role on a subgroup that's lower than the roles they have on ancestor groups. To override a user's
+role on an ancestor group, add the user to the subgroup again with a higher role. For example:
 
-## Limitations
+- If User 1 is added to group _Two_ with the Developer role, they inherit that role in every subgroup of group _Two_.
+- To give User 1 the Maintainer role on group _Four_ (under _One / Two / Three_), add them again to group _Four_ with
+  the Maintainer role.
+- If User 1 is removed from group _Four_, their role falls back to their role on group _Two_. They have the Developer
+  role on group _Four_ again.
 
-Here's a list of what you can't do with subgroups:
+## Mention subgroups
 
-- [GitLab Pages](../../project/pages/index.md) supports projects hosted under
-  a subgroup, but not subgroup websites.
-  That means that only the highest-level group supports
-  [group websites](../../project/pages/getting_started_part_one.md#gitlab-pages-default-domain-names),
-  although you can have project websites under a subgroup.
-- It is not possible to share a project with a group that's an ancestor of
-  the group the project is in. That means you can only share as you walk down
-  the hierarchy. For example, `group/subgroup01/project` **cannot** be shared
-  with `group`, but can be shared with `group/subgroup02` or
-  `group/subgroup01/subgroup03`.
+Mentioning subgroups ([`@<subgroup_name>`](../../discussions/index.md#mentions)) in issues, commits, and merge requests
+notifies all members of that group. Mentioning works the same as for projects and groups, and you can choose the group
+of people to be notified.
 
 <!-- ## Troubleshooting
 

doc/user/permissions.md

@@ -431,8 +431,7 @@ The following table lists group permissions available for each role:
 
 <!-- markdownlint-disable MD029 -->
 
-1. Groups can be set to [allow either Owners or Owners and
-  Maintainers to create subgroups](group/subgroups/index.md#creating-a-subgroup)
+1. Groups can be set to allow either Owners, or Owners and users with the Maintainer role, to [create subgroups](group/subgroups/index.md#create-a-subgroup).
 2. Introduced in GitLab 12.2.
 3. Default project creation role can be changed at:
    - The [instance level](admin_area/settings/visibility_and_access_controls.md#define-which-roles-can-create-projects).
@@ -451,7 +450,7 @@ permission level from the parent group(s). This model allows access to
 nested groups if you have membership in one of its parents.
 
 To learn more, read through the documentation on
-[subgroups memberships](group/subgroups/index.md#membership).
+[subgroups memberships](group/subgroups/index.md#subgroup-membership).
 
 ## External users **(FREE SELF)**
 

doc/user/project/members/share_project_with_groups.md

@@ -15,7 +15,7 @@ Groups are used primarily to [create collections of projects](../../group/index.
 take advantage of the fact that groups define collections of _users_, namely the group
 members.
 
-## Sharing a project with a group of users
+## Share a project with a group of users
 
 NOTE:
 In GitLab 13.11, you can [replace this form with a modal window](#share-a-project-modal-window).
@@ -89,7 +89,15 @@ Feature.disable(:invite_members_group_modal)
 
 In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Maintainer' or 'Owner') only have 'Developer' access to 'Project Acme'.
 
-## Sharing public project with private group
+### Share a project with a subgroup
+
+You can't share a project with a group that's an ancestor of a [subgroup](../../group/subgroups/index.md) the project is
+in. That means you can only share down the hierarchy. For example, `group/subgroup01/project`:
+
+- Can not be shared with `group`.
+- Can be shared with `group/subgroup02` or  `group/subgroup01/subgroup03`.
+
+## Share public project with private group
 
 When sharing a public project with a private group, owners and maintainers of the project see the name of the group in the `members` page. Owners also have the possibility to see members of the private group they don't have access to when mentioning them in the issue or merge request.
 

doc/user/project/merge_requests/approvals/rules.md

@@ -175,7 +175,7 @@ granting them push access:
 1. [Create a new group](../../../group/index.md#create-a-group).
 1. [Add the user to the group](../../../group/index.md#add-users-to-a-group),
    and select the Reporter role for the user.
-1. [Share the project with your group](../../members/share_project_with_groups.md#sharing-a-project-with-a-group-of-users),
+1. [Share the project with your group](../../members/share_project_with_groups.md#share-a-project-with-a-group-of-users),
    based on the Reporter role.
 1. Go to your project and select **Settings > General**.
 1. Expand **Merge request (MR) approvals**.

doc/user/project/pages/getting_started_part_one.md

@@ -34,7 +34,7 @@ Pages domains are `*.gitlab.io`.
 | Project pages owned by a subgroup | `subgroup/projectname` | `http(s)://groupname.example.io/subgroup/projectname`|
 
 WARNING:
-There are some known [limitations](introduction.md#limitations)
+There are some known [limitations](introduction.md#subdomains-of-subdomains)
 regarding namespaces served under the general domain name and HTTPS.
 Make sure to read that section.
 

doc/user/project/pages/introduction.md

@@ -76,17 +76,21 @@ website.
 
 ![Remove pages](img/remove_pages.png)
 
-## Limitations
+## Subdomains of subdomains
 
-When using Pages under the general domain of a GitLab instance (`*.example.io`),
-you _cannot_ use HTTPS with sub-subdomains. That means that if your
-username or group name contains a dot, for example `foo.bar`, the domain
-`https://foo.bar.example.io` does _not_ work. This is a limitation of the
-[HTTP Over TLS protocol](https://tools.ietf.org/html/rfc2818#section-3.1).
-HTTP pages continue to work provided you don't redirect HTTP to HTTPS.
+When using Pages under the top-level domain of a GitLab instance (`*.example.io`), you can't use HTTPS with subdomains
+of subdomains. If your namespace or group name contains a dot (for example, `foo.bar`) the domain
+`https://foo.bar.example.io` does _not_ work.
 
-GitLab Pages [does **not** support group websites for subgroups](../../group/subgroups/index.md#limitations).
-You can only create the highest-level group website.
+This limitation is because of the [HTTP Over TLS protocol](https://tools.ietf.org/html/rfc2818#section-3.1). HTTP pages
+work as long as you don't redirect HTTP to HTTPS.
+
+## GitLab Pages and subgroups
+
+You must host your GitLab Pages website in a project. This project can belong to a [group](../../group/index.md) or
+[subgroup](../../group/subgroups/index.md). For
+[group websites](../../project/pages/getting_started_part_one.md#gitlab-pages-default-domain-names), the group must be
+at the top level and not a subgroup.
 
 ## Specific configuration options for Pages
 

locale/gitlab.pot

@@ -16705,7 +16705,7 @@ msgstr ""
 msgid "GitLabPages|When enabled, all attempts to visit your website through HTTP are automatically redirected to HTTPS using a response with status code 301. Requires a valid certificate for all domains. %{docs_link_start}Learn more.%{link_end}"
 msgstr ""
 
-msgid "GitLabPages|When using Pages under the general domain of a GitLab instance (%{pages_host}), you cannot use HTTPS with sub-subdomains. This means that if your username/groupname contains a dot it will not work. This is a limitation of the HTTP Over TLS protocol. HTTP pages will continue to work provided you don't redirect HTTP to HTTPS. %{docs_link_start}Learn more.%{link_end}"
+msgid "GitLabPages|When using Pages under the general domain of a GitLab instance (%{pages_host}), you cannot use HTTPS with subdomains of subdomains. If your namespace or groupname contains a dot, it does not work. This is a limitation of the HTTP Over TLS protocol. HTTP pages work if you don't redirect HTTP to HTTPS. %{docs_link_start}Learn more.%{link_end}"
 msgstr ""
 
 msgid "GitLabPages|With GitLab Pages you can host your static website directly from your GitLab repository. %{docs_link_start}Learn more.%{link_end}"