New Crowdin updates

docs/books/web_services/052-load-balancer-proxies-varnish.uk.md

@@ -327,7 +327,7 @@ sub vcl_backend_response {
 
 #### Розповсюдження запитів на різні бекенди
 
-Якщо розміщено кілька сайтів, наприклад сервер документів (\<docs.rockylinux.org>) і вікі (\<wiki.rockylinux.org>), можна розподіляти запити на правильну серверну частину.
+Якщо розміщено кілька сайтів, наприклад сервер документів (<docs.rockylinux.org>) і вікі (<wiki.rockylinux.org>), можна розподіляти запити на правильну серверну частину.
 
 Оголошення бекендів:
 
@@ -438,7 +438,7 @@ site.front02                   probe      Healthy 5/5
 varnishadm backend.set_health site.front01 auto
 ```
 
-Оголошення серверних модулів виконується наступним чином: https://github.com/mattiasgeniar/varnish-6.0-configuration-templates.
+Оголошення серверних модулів виконується наступним чином: <https://github.com/mattiasgeniar/varnish-6.0-configuration-templates>.
 
 ### Журнали Apache
 

docs/desktop/gnome/rdp-server.fr.md

@@ -12,7 +12,9 @@ Pour les débutants, vous allez utiliser RDP. RDP signifie Remote Desktop Protoc
 
 !!! note "Remarque"
 
-Par défaut, Rocky Linux vous permet de partager votre desktop via un autre protocole VNC. VNC est assez pratique, mais RDP offre généralement une expérience beaucoup plus fluide et peut gérer des résolutions de moniteur inhabituelles.
+```
+Par défaut, Rocky Linux vous permet de partager votre bureau via un autre protocole VNC. VNC est assez pratique, mais RDP offre généralement une expérience beaucoup plus fluide et peut gérer des résolutions d'écran inhabituelles.
+```
 
 ## Prérequis
 

docs/gemstones/git/02_github_web_edit_pr_title.fr.md

@@ -0,0 +1,44 @@
+---
+title: Changement du titre d'une demande de Pull Request via github.com
+author: Wale Soyinka
+contributors: Ganna Zhyrnova
+tags:
+  - GitHub
+  - Pull Request
+  - Documentation
+---
+
+## Introduction
+
+Ce guide explique comment modifier ou changer le titre d'une demande de Pull Request (PR) active dans un référentiel GitHub à l'aide de l'interface Web GitHub.
+
+## Description du Problème
+
+Parfois, il peut être nécessaire de modifier le titre d'une requête PR après sa création pour mieux refléter les changements ou les discussions en cours.
+
+## Prérequis
+
+- Une pull request GitHub en cours de traitement.
+- Accès à l'interface Web GitHub ou CLI avec les autorisations nécessaires.
+
+## Procédure
+
+### Utilisation de l'interface Web de GitHub
+
+1. **Accéder à la requète Pull Request**:
+   - Accédez au référentiel où se trouve la requête PR.
+   - Cliquez sur `Pull requests` et sélectionnez la requête PR que vous souhaitez modifier.
+
+2. **Édition du Titre de PR**:
+   - Cliquez sur le titre de la Pull Request.
+   - Une boîte de texte modifiable apparaîtra.
+   - Modifiez le titre, appuyez sur ++enter++ ou cliquez en dehors de la zone de texte pour enregistrer les modifications.
+
+## Informations Supplémentaires (facultatif)
+
+- La modification d'un titre de PR n'affectera pas son fil de discussion ni les modifications de code.
+- Il est considéré comme une bonne pratique d'informer les collaborateurs si des modifications significatives sont apportées au titre d'un PR.
+
+## Conclusion
+
+En suivant ces étapes, vous pouvez facilement modifier le titre d’une demande Pull Request active dans un référentiel GitHub via l’interface Web.

docs/gemstones/git/feature_branch_workflow.fr.md

@@ -0,0 +1,99 @@
+---
+title: Feature Branch Workflow avec Git
+author: Wale Soyinka
+contributors: Ganna Zhyrnova
+tags:
+  - git
+  - Workflow de branche de fonctionnalités
+  - GitHub
+  - gh
+  - git fetch
+  - git add
+  - git pull
+  - git checkout
+---
+
+## Workflow de branche de fonctionnalités
+
+Ce workflow git répandu implique la création de nouvelles branches pour chaque nouvelle fonctionnalité ou correctif directement dans le référentiel principal.
+Il est généralement utilisé dans les projets où les contributeurs ont un accès direct au référentiel.
+
+Ce Gemstone décrit le processus de configuration d'un référentiel local sur lequel travailler et contribuer au projet `rocky-linux/documentation` à l'aide du workflow Git Feature Branch.
+
+L'utilisateur "rockstar" a créé un fork de ce référentiel et nous utiliserons `https://github.com/rockstar/documentation` comme origine.
+
+## Prérequis
+
+- Un compte GitHub et un fork du projet (par exemple, `https://github.com/rockstar/documentation`).
+- L'installation de `git` et `GitHub CLI (gh)`.
+
+## Procédure
+
+1. Si besoin est, clonez votre fork :
+
+   ```bash
+   git clone https://github.com/rockstar/documentation.git
+   cd documentation
+   ```
+
+2. Ajoutez `upstream remote` :
+
+   ```bash
+   git remote add upstream https://github.com/rocky-linux/documentation.git
+   ```
+
+3. Récupérer les modifications en amont :
+
+   ```bash
+   git fetch upstream
+   ```
+
+4. Créer une nouvelle branche, Feature Branch :
+
+   ```bash
+   git checkout -b feature-branch-name
+   ```
+
+5. Apportez des modifications, ajoutez de nouveaux fichiers et validez-les avec `commit` :
+
+   ```bash
+   git add .
+   git commit -m "Implementing feature X"
+   ```
+
+6. Maintenir votre Branche à Jour. Fusionnez régulièrement les modifications en amont avec `pull` pour éviter les conflits :
+
+   ```bash
+   git pull upstream main --rebase
+   ```
+
+7. Transmettez vers votre fork en tapant :
+
+   ```bash
+   git push origin feature-branch-name
+   ```
+
+8. Créer un Pull Request :
+
+   ```bash
+   gh pr create --base main --head rockstar:feature-branch-name --title "New Feature X" --body "Long Description of the feature"
+   ```
+
+## Conclusion
+
+Le workflow Feature Branch est une technique de collaboration courante, permettant aux équipes de travailler simultanément sur divers aspects d'un projet tout en conservant une base de code principale stable.
+
+Les étapes principales sont les suivantes :
+
+1. Cloner le référentiel principal : clonez directement le référentiel principal du projet sur votre machine locale.
+2. Créer une branche de fonctionnalités : pour chaque nouvelle tâche, créez une nouvelle branche de la branche principale avec un nom descriptif.
+3. Valider les modifications : travaillez sur la fonctionnalité ou le correctif dans votre branche et validez les modifications avec `commit`.
+4. Maintenir la branche à jour : fusionnez avec `pull` ou rebasez régulièrement avec la branche principale pour rester synchrone avec d'éventuelles modifications.
+5. Ouvrez une Pull Request : envoyez la branche au référentiel principal avec `push` et ouvrez une PR pour examen une fois que votre fonctionnalité est prête à vérifier.
+6. Révision et fusion du code : la branche est fusionnée dans la branche principale avec `merge` après vérification et approbation.
+
+_Avantages :_
+
+- Simplifie les contributions pour les contributeurs réguliers avec un accès direct au référentiel.
+- Assure que chaque fonctionnalité est examinée et vérifiée avant d'être intégrée à la base de code principale.
+- Permet de maintenir un historique de projet propre et linéaire.

docs/gemstones/git/fork_and_branch_workflow.fr.md

@@ -0,0 +1,115 @@
+---
+title: Fork et Branche – Git workflow
+author: Wale Soyinka
+contributors: Ganna Zhyrnova
+tags:
+  - GitHub
+  - git
+  - gh
+  - git fetch
+  - git add
+  - git pull
+  - git checkout
+  - gh repo
+---
+
+## Fork et Branch Workflow
+
+Dans ce type de workflow, les contributeurs transfèrent le référentiel principal vers un fork dans leur propre compte GitHub, créent des branches de fonctionnalités pour leur travail, puis soumettent des contributions via des Pull Requests depuis ces branches.
+
+Ce Gemstone explique comment configurer un référentiel local pour contribuer à un projet GitHub. Cela commence par le fork initial du projet, la configuration d'un référentiel local et distant, la validation des modifications et la création d'une pull request (PR) pour soumettre vos contributions.
+
+## Prérequis
+
+- Un compte GitHub.
+- Installation de `git` et `GitHub CLI (gh)` sur votre système.
+- Un fork individuel du projet sur GitHub.
+
+## Procédure
+
+1. S'il n'existe pas déjà, créez un fork du projet en utilisant l'utilitaire `gh`. Entrer la commande suivante :
+
+   ```bash
+   gh repo fork rocky-linux/documentation --clone=true --remote=true
+   ```
+
+   Les options utilisées dans cette commande _gh repo fork_ sont les suivantes :
+
+   - `--clone=true` : Clone le référentiel forké sur votre machine locale.
+   - `--remote=true` : ajoute le référentiel d'origine en tant que référentiel distant, vous permettant de synchroniser les futures mises à jour.
+
+2. Accédez au répertoire du dépôt local. Entrer la commande suivante :
+
+   ```bash
+   cd documentation
+   ```
+
+3. Vérifiez que tous les dépôts distants pertinents ont été correctement configurés dans votre dépôt local, tapez :
+
+   ```bash
+   git remote -vv
+   ```
+
+4. Récupérez les dernières modifications avec `fetch` depuis le dépôt distant en amont :
+
+   ```bash
+   git fetch upstream
+   ```
+
+5. Créez et extrayez avec `checkout` une nouvelle branche de fonctionnalités nommée your-feature-branch :
+
+   ```bash
+   git checkout -b your-feature-branch
+   ```
+
+6. Apportez des modifications, ajoutez de nouveaux fichiers et validez vos modifications dans votre dépôt local avec `commit` :
+
+   ```bash
+   git add .
+   git commit -m "Your commit message"
+   ```
+
+7. Synchronisez avec la branche principale du dépôt distant nommée « upstream » :
+
+   ```bash
+   git pull upstream main
+   ```
+
+8. Transmission des modifications au Fork :
+
+   ```bash
+   git push origin your-feature-branch
+   ```
+
+9. Enfin, créez une Pull Request (PR) à l'aide de l'application CLI `gh` :
+
+   ```bash
+   gh pr create --base main --head your-feature-branch --title "Your PR Title" --body "Description of your changes"
+   ```
+
+   Les options utilisées dans cette commande _gh pr create_ sont les suivantes :
+
+   `--base` main : spécifie la branche de base dans le référentiel upstream où les modifications seront fusionnées avec `merge`.
+   `--head` your-feature-branch : indique la branche principale de votre fork qui contient les modifications.
+   `--title` "Votre titre PR" : définit le titre de la demande de Pull Request.
+   `--body` "Description de vos modifications" : Fournit une description détaillée des modifications dans la pull request.
+
+## Conclusion
+
+Le workflow `Fork and Branch` est une autre technique de collaboration courante.
+Les étapes principales sont les suivantes :
+
+1. Fork Repository : créez une copie individuelle du référentiel du projet sur votre compte GitHub.
+2. Clone du fork : clonez votre fork sur votre machine locale pour les travaux de développement.
+3. Définir le site distant en amont : pour rester à jour avec ses modifications, ajoutez le référentiel du projet d'origine en tant que site distant `upstream remote`.
+4. Création d'une Feature Branch : créez une nouvelle branche à partir de la branche principale mise à jour pour chaque nouvelle fonctionnalité ou correctif. Les noms de branche doivent décrire succinctement la fonctionnalité ou le correctif.
+5. Commit des modifications : effectuez vos modifications et validez-les – `commit` – avec des messages de validation clairs et concis.
+6. Synchronisation avec Upstream : synchronisez régulièrement votre fork et votre branche de fonctionnalité avec la branche principale en amont – `Upstream` – pour intégrer les nouvelles modifications et réduire les conflits de fusion – `merge` – .
+7. Création d'une Pull Request (PR) : envoyez votre branche de fonctionnalité à votre fork sur GitHub avec `push` et ouvrez une PR sur le projet principal. Votre PR doit décrire clairement les changements et établir un lien vers tout problème pertinent et toute demande d'amélioration ou de nouvelle fonctionnalité.
+8. Répondre aux commentaires : collaborer sur les commentaires de révision jusqu'à ce que la PR soit fusionnée – `merge` – ou fermée.
+
+Avantages :
+
+- Isole le travail de développement dans des branches spécifiques, tout en gardant la branche principale propre.
+- Cela facilite la révision et l’intégration des modifications.
+- Réduit le risque de conflits avec la base de code évolutive du projet principal.

docs/gemstones/git/git_pull_vs_git_fetch.fr.md

@@ -0,0 +1,70 @@
+---
+title: Utilisation de `git pull` et `git fetch`
+author: Wale Soyinka
+contributors: Ganna Zhyrnova
+tags:
+  - Git
+  - git pull
+  - git fetch
+---
+
+## Introduction
+
+Ce Gemstone explique les différences entre les commandes `git pull` et `git fetch`. Il indique également quand utiliser chaque commande de manière appropriée.
+
+## Git Fetch vs Git Pull
+
+### Git Fetch
+
+`git fetch` télécharge les modifications à partir d'un référentiel distant mais ne les intègre pas dans votre branche locale.
+
+Il est bénéfique de voir ce que les autres ont apporté avec commit sans fusionner ces modifications dans votre branche locale.
+
+1. Lister la branche actuellement extraite
+
+   ```bash
+   git branch
+   ```
+
+2. Récupérer les modifications avec `fetch` depuis la branche principale d'un référentiel distant nommé origin. Entrer la commande suivante :
+
+   ```bash
+   git fetch origin main
+   ```
+
+3. Comparez les modifications entre le HEAD de votre dépôt local et le dépôt `origin/main` distant.
+
+   ```bash
+   git log HEAD..origin/main
+   ```
+
+### Git Pull
+
+Git Pull télécharge les modifications et les fusionne dans votre branche actuelle.
+Il est utile pour mettre à jour rapidement votre branche locale avec les modifications du référentiel distant.
+
+1. **Extraire et fusionner les modifications** :
+
+   ```bash
+   git pull origin main
+   ```
+
+2. **Vérifiez les modifications fusionnées** :
+
+   ```bash
+   git log
+   ```
+
+## Remarques Complémentaires
+
+- **Utilisez `git fetch`** :
+  \-- Lorsque vous devez vérifier les modifications avant la fusion.
+  \-- Éviter des changements indésirables ou des conflits dans votre branche locale.
+
+- **Utilisez `git pull`** :
+  \-- Lorsque vous souhaitez mettre à jour votre branche locale avec les derniers commits.
+  \-- Pour des mises à jour rapides et simples sans avoir à vérifier les modifications au préalable.
+
+## Conclusion
+
+Comprendre les distinctions entre `git fetch` et `git pull` est essentiel pour une gestion efficace du workflow Git. Choisir la bonne commande en fonction de vos besoins est important lorsque vous travaillez ou collaborez via des systèmes de contrôle de version comme GitHub, GitLab, Gitea, etc.