Merge branch 'mjang-master-main-manage-docs' into 'master'

Language change, Manage docs: Convert master to default (mostly)

See merge request gitlab-org/gitlab!58586

doc/development/i18n/externalization.md

@@ -256,7 +256,7 @@ For example use `%{created_at}` in Ruby but `%{createdAt}` in JavaScript. Make s
 - In Vue:
 
   Use the [`GlSprintf`](https://gitlab-org.gitlab.io/gitlab-ui/?path=/docs/utilities-sprintf--sentence-with-link) component if:
-  
+
   - you need to include child components in the translation string.
   - you need to include HTML in your translation string.
   - you are using `sprintf` and need to pass `false` as the third argument to
@@ -699,7 +699,7 @@ bin/rake gettext:regenerate
 
 This command updates `locale/gitlab.pot` file with the newly externalized
 strings and remove any strings that aren't used anymore. You should check this
-file in. Once the changes are on master, they are picked up by
+file in. Once the changes are on the default branch, they are picked up by
 [CrowdIn](https://translate.gitlab.com) and be presented for
 translation.
 

doc/development/i18n/merging_translations.md

@@ -42,10 +42,11 @@ page](https://translate.gitlab.com/project/gitlab-ee/settings#integration).
 
 ## Merging translations
 
-When all translations are found good and pipelines pass the
-translations can be merged into the master branch. When merging the translations,
-make sure to check the **Remove source branch** checkbox, so CrowdIn recreates the
-`master-i18n` from master after the new translation was merged.
+After all translations are determined to be appropriate and the pipelines pass,
+you can merge the translations into the default branch. When merging translations,
+be sure to select the **Remove source branch** check box, which causes CrowdIn
+to recreate the `master-i18n` from the default branch after merging the new
+translation.
 
 We are discussing [automating this entire process](https://gitlab.com/gitlab-org/gitlab/-/issues/19896).
 
@@ -59,7 +60,7 @@ and delete the
 [`master-18n`](https://gitlab.com/gitlab-org/gitlab/-/branches/all?utf8=✓&search=master-i18n).
 
 This might be needed when the merge request contains failures that
-have been fixed on master.
+have been fixed on the default branch.
 
 ## Recreate the GitLab integration in CrowdIn
 

doc/user/project/import/perforce.md

@@ -15,33 +15,33 @@ include a centralized, proprietary version control system similar to Git.
 The following list illustrates the main differences between Perforce Helix and
 Git:
 
-1. In general the biggest difference is that Perforce branching is heavyweight
-   compared to Git's lightweight branching. When you create a branch in Perforce,
-   it creates an integration record in their proprietary database for every file
-   in the branch, regardless how many were actually changed. Whereas Git was
-   implemented with a different architecture so that a single SHA acts as a pointer
-   to the state of the whole repository after the changes, making it very easy to branch.
-   This is what made feature branching workflows so easy to adopt with Git.
-1. Also, context switching between branches is much easier in Git. If your manager
-   said 'You need to stop work on that new feature and fix this security
-   vulnerability' you can do so very easily in Git.
-1. Having a complete copy of the project and its history on your local machine
-   means every transaction is very fast and Git provides that. You can branch/merge
-   and experiment in isolation, then clean up your mess before sharing your new
-   cool stuff with everyone.
-1. Git also made code review simple because you could share your changes without
-   merging them to master, whereas Perforce had to implement a Shelving feature on
-   the server so others could review changes before merging.
+- In general, the biggest difference is that Perforce branching is heavyweight
+  compared to Git's lightweight branching. When you create a branch in Perforce,
+  it creates an integration record in their proprietary database for every file
+  in the branch, regardless how many were actually changed. With Git, however,
+  a single SHA acts as a pointer to the state of the whole repository after the
+  changes, which can be helpful when adopting feature branching workflows.
+- Context switching between branches is less complex in Git. If your manager
+  says, 'You need to stop work on that new feature and fix this security
+  vulnerability,' Git can help you do this.
+- Having a complete copy of the project and its history on your local computer
+  means every transaction is very fast, and Git provides that. You can branch
+  or merge, and experiment in isolation, and then clean up before sharing your
+  changes with others.
+- Git makes code review less complex, because you can share your changes without
+  merging them to the default branch. This is compared to Perforce, which had to
+  implement a Shelving feature on the server so others could review changes
+  before merging.
 
 ## Why migrate
 
 Perforce Helix can be difficult to manage both from a user and an administrator
 perspective. Migrating to Git/GitLab there is:
 
-- **No licensing costs**, Git is GPL while Perforce Helix is proprietary.
-- **Shorter learning curve**, Git has a big community and a vast number of
+- **No licensing costs**: Git is GPL while Perforce Helix is proprietary.
+- **Shorter learning curve**: Git has a big community and a vast number of
   tutorials to get you started.
-- **Integration with modern tools**, migrating to Git and GitLab you can have
+- **Integration with modern tools**: By migrating to Git and GitLab, you can have
   an open source end-to-end software development platform with built-in version
   control, issue tracking, code review, CI/CD, and more.