From c27dced6e9653ffd107077100a6523cd4e6293c7 Mon Sep 17 00:00:00 2001 From: Anthony Dahanne Date: Mon, 10 Jun 2019 23:02:21 -0400 Subject: [PATCH] Fix several potential issues with existing translation (#14785) * some typos * some weird formulations, copied from the original english sentence * some missing translations --- content/fr/docs/contribute/_index.md | 8 +- .../generate-ref-docs/kubernetes-api.md | 20 ++--- content/fr/docs/contribute/start.md | 90 +++++++++---------- content/fr/docs/home/_index.md | 4 +- content/fr/docs/setup/_index.md | 14 ++- content/fr/docs/tutorials/hello-minikube.md | 21 +++-- 6 files changed, 77 insertions(+), 80 deletions(-) diff --git a/content/fr/docs/contribute/_index.md b/content/fr/docs/contribute/_index.md index 61b614bcc5..60170f8396 100644 --- a/content/fr/docs/contribute/_index.md +++ b/content/fr/docs/contribute/_index.md @@ -22,7 +22,7 @@ Pour plus d'informations sur le guide de style de la documentation Kubernetes, r - Un _membre_ de l'organisation Kubernetes qui a [signé le CLA](/docs/contribute/start#sign-the-cla) et contribué un peu de temps et d'efforts au projet. Voir [Adhésion à la communauté](https://github.com/kubernetes/community/blob/master/community-membership.md) pour des critères spécifiques d'adhésion. - Un SIG Docs _relecteur_ est un membre de l'organisation Kubernetes qui -  a exprimé son intérêt pour l'examen des Pull Requests de la documentation et qui a été ajouté au groupe GitHub approprié et aux fichiers `OWNERS` dans le GitHub référentiel, par un approbateur SIG Docs. +  a exprimé son intérêt pour l'examen des Pull Requests de la documentation et qui a été ajouté au groupe GitHub approprié et aux fichiers `OWNERS` dans le dépôt GitHub, par un approbateur SIG Docs. - Un SIG Docs _approbateur_ est un membre en règle qui a démontré un engagement continu envers le projet. Un approbateur peut fusionner des Pull Requests et publier du contenu au nom de l'organisation Kubernetes. Les approbateurs peuvent également représenter les documents SIG dans la communauté plus large de Kubernetes. @@ -30,13 +30,13 @@ Pour plus d'informations sur le guide de style de la documentation Kubernetes, r ## Façons de contribuer -Cette liste est divisée en tâches que tout le monde peut faire, que peuvent faire les membres d’une organisation Kubernetes et qui requièrent un niveau d’accès supérieur et une familiarité avec les processus SIG Docs. +Cette liste est divisée en tâches accessibles à tous, ou juste aux membres de l'organisation Kubernetes, ou encore en tâches requérant un haut niveau d'autorisation et de familiarité avec les processus SIG Docs. Contribuer de manière constante au fil du temps peut vous aider à comprendre certaines des décisions relatives à l’outillage et à l’organisation qui ont déjà été prises. Il ne s'agit pas d'une liste exhaustive des manières dont vous pouvez contribuer à la documentation de Kubernetes, mais cela devrait vous aider à démarrer. - [N'importe qui](/docs/contribute/start/) - - Remplir des rapports de bugs reproductibles + - Remplir des rapports d'anomalie reproductibles - [Membre](/docs/contribute/start/) - Améliorer la documentation existante - Proposer des idées d'améliorations sur [Slack](http://slack.k8s.io/) ou sur la [liste de diffusion SIG docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) @@ -47,7 +47,7 @@ Il ne s'agit pas d'une liste exhaustive des manières dont vous pouvez contribue - Documenter les nouvelles fonctionnalités - Trier et classer les problèmes - Relire des PRs - - Créez des diagrammes, des ressources graphiques et des vidéos / screencasts incorporables + - Créez des diagrammes, des ressources graphiques et des vidéos / capture vidéo d'écran incorporables - Localisation - Contribuer à d'autres dépôts en tant que représentant de la documentation - Éditer des chaînes pour l'utilisateur dans le code diff --git a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md index 1305b506a4..edf56ff826 100644 --- a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -65,7 +65,7 @@ Déterminez le répertoire de base de votre dépôt [kubernetes/website](https:/ Par exemple, si vous avez suivi l’étape précédente pour obtenir le dépôt, votre répertoire de base est `$GOPATH/src/github.com/kubernetes/website`. Les étapes restantes se réfèrent à votre répertoire de base en tant que ``. -Si vous n'avez pas déjà le dépôt `kubernetes-incubator/reference-docs`, l'obtenir maintenant: +Si vous n'avez pas déjà le dépôt `kubernetes-incubator/reference-docs`, obtenez-le maintenant: ```shell mkdir $GOPATH/src @@ -121,7 +121,7 @@ On branch master ### Valider votre fichier édité -Exécutez `git add` et` git commit` pour valider les modifications que vous avez apportées jusqu'à présent. +Exécutez `git add` et ` git commit` pour valider les modifications que vous avez apportées jusqu'à présent. Dans l'étape suivante, vous ferez un deuxième commit. Il est important de séparer vos modifications en deux commits. @@ -154,7 +154,7 @@ Voir le contenu de `api/openapi-spec/swagger.json` pour vous assurer que la faut Par exemple, vous pouvez exécuter `git diff -a api/openapi-spec/swagger.json`. Ceci est important, car `swagger.json` sera l’entrée de la seconde étape du processus de génération de doc. -Exécutez `git add` et` git commit` pour valider vos modifications. +Exécutez `git add` et ` git commit` pour valider vos modifications. Vous avez maintenant deux validations: une avec le fichier `types.go` édité et une avec les spécifications OpenAPI générées et les fichiers associés. Gardez ces deux commits séparés. C'est-à-dire, ne faites pas un squash de vos commits. @@ -182,14 +182,14 @@ Par exemple, supposons que la branche principale soit utilisée pour développer Rappelez-vous que votre pull request a deux commits: un pour l'édition `types.go` et un pour les fichiers générés par des scripts. La prochaine étape consiste à proposer un cherry pick de votre premier commit dans la branche release-1.9. L'idée est de cherry pick le commit qui a édité `types.go`, mais pas le commit qui a pour résultat l'exécution des scripts. -Pour les instructions, voir [Propose un Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md). +Pour les instructions, voir [Proposer un Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md). {{< note >}} Proposer un cherry pick nécessite que vous ayez la permission de définir un label et un milestone dans votre pull request. Si vous ne disposez pas de ces autorisations, vous devrez travailler avec une personne pouvant définir les labels et milestones pour vous. {{< /note >}} -Quand vous avez un pull request en place pour cherry picking votre seul engagement dans la branche release-1.9, l’étape suivante consiste à exécuter ces scripts dans la branche release-1.9 de votre environnement local. +Quand vous avez une pull request en place pour cherry picking votre seul commit dans la branche release-1.9, l’étape suivante consiste à exécuter ces scripts dans la branche release-1.9 de votre environnement local. ```shell hack/update-generated-swagger-docs.sh @@ -211,7 +211,7 @@ Les fichiers générés dans la branche maître peuvent contenir des éléments La section précédente a montré comment modifier un fichier source, puis générer plusieurs fichiers, y compris `api/openapi-spec/swagger.json` dans le dépôt `kubernetes/kubernetes`. -Cette section montre comment générer le [documentation de référence de l'API Kubernetes publiée](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/), qui est généré par les outils de [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs). +Cette section montre comment générer la [documentation de référence de l'API Kubernetes publiée](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/), qui est générée par les outils de [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs). Ces outils prennent le fichier `api/openapi-spec/swagger.json` comme entrée. ### Modification du Makefile dans kubernetes-incubator/reference-docs @@ -300,7 +300,7 @@ Entrez la commande suivante pour copier les fichiers générés dans votre dép make copyapi ``` -Allez à la base de votre dépôt local `kubernetes/kubernetes`, et voir quels fichiers ont été modifiés: +Allez à la base de votre dépôt local `kubernetes/kubernetes`, et regardez quels fichiers ont été modifiés: ```shell cd @@ -322,10 +322,10 @@ Mais apparemment le généré `navata.js` n'est pas différent du `navData.js` c Dans `` executez `git add` et `git commit` pour enregistrer le commit du changement. Soumettez vos modifications en tant que [pull request](/docs/home/contribute/create-pull-request/) au dépôt [kubernetes/website](https://github.com/kubernetes/website). -Surveillez votre pull request, et répondre aux commentaires des relecteurs au besoin. -Continuez à surveiller votre pull request jusqu'à ce qu'il ait été mergé. +Surveillez votre pull request, et répondez aux commentaires des relecteurs au besoin. +Continuez à surveiller votre pull request jusqu'à ce qu'elle ait été mergée. -Quelques minutes après que votre pull request soit mergée, vos modifications seront visibles dans le [documentation de référence publiée](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). +Quelques minutes après que votre pull request soit fusionnée, vos modifications seront visibles dans la [documentation de référence publiée](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). {{% /capture %}} diff --git a/content/fr/docs/contribute/start.md b/content/fr/docs/contribute/start.md index 04ffbdb38c..859d490890 100644 --- a/content/fr/docs/contribute/start.md +++ b/content/fr/docs/contribute/start.md @@ -28,7 +28,7 @@ Le code source est sur GitHub: [https://github.com/kubernetes/website](https://g La majeure partie de la documentation anglaise est stockée dans `/content/en/docs/`. Une partie de la documentation de référence est automatiquement générée à partir de scripts du répertoire `update-imported-docs/`. -Vous pouvez trier les issues, modifier le contenu et passer en revue les modifications des autres, le tout à partir du site Web de GitHub. +Vous pouvez trier les demandes, modifier le contenu et passer en revue les modifications des autres, le tout à partir du site Web de GitHub. Vous pouvez également utiliser l'historique intégré et les outils de recherche de GitHub. Toutes les tâches ne peuvent pas être effectuées dans l’interface utilisateur GitHub, mais elles sont décrites dans les guides de contribution [intermédiaire](/docs/contribute/intermediate/) et [avancé](/docs/contribute/advanced/). @@ -40,7 +40,7 @@ Nous communiquons via un canal Slack, une liste de diffusion et des réunions vi Les nouveaux participants sont les bienvenus. Pour plus d'informations, voir [Participer au SIG-docs](/docs/contribute/participating/). -### Style guidelines +### Guides de style Nous maintenons un [guide de style](/docs/contribute/style/style-guide/) avec des informations sur les choix de la communauté SIG Docs concernant la grammaire, la syntaxe, le format des sources et les conventions typographiques. Avant de faire votre première contribution, parcourez le guide de style et utilisez-le lorsque vous avez des questions. @@ -54,7 +54,7 @@ Voir le sujet [contribution avancée](/docs/contribute/advanced/) pour plus d'in Nous utilisons des modèles de page pour contrôler la présentation de nos pages de documentation. Assurez-vous de comprendre le fonctionnement de ces modèles en consultant [Utilisation de modèles de page](/docs/contribute/style/page-templates/). -### Hugo shortcodes +### Shortcodes Hugo La documentation de Kubernetes est convertie de Markdown à HTML avec Hugo. Nous utilisons les shortcodes standard Hugo, ainsi que quelques-uns qui sont personnalisés dans la documentation Kubernetes. @@ -70,7 +70,7 @@ Pour plus d'informations sur la contribution à la documentation dans plusieurs Si vous souhaitez démarrer une nouvelle traduction, voir ["Traduction"](/docs/contribute/localization/). -## Déposer les problèmes pouvant faire l'objet d'une action +## Créer des demander recevables Toute personne possédant un compte GitHub peut soumettre un problème (rapport de bogue) à la documentation de Kubernetes. Si vous voyez quelque chose qui ne va pas, même si vous ne savez pas comment le réparer, [ouvrez un ticket](#how-to-file-an-issue). @@ -91,7 +91,7 @@ Dans ce cas, vous pouvez plutôt [le réparer](#improve-existing-content) sans d - **Demander une nouvelle page** - Si vous pensez que le contenu doit exister, mais que vous ne savez pas où il doit aller ou si vous pensez qu'il ne correspond pas aux pages existantes, vous pouvez toujours ouvrir un ticket. + Si vous pensez que du contenu est manquant, mais que vous ne savez pas où il doit aller ou si vous pensez qu'il ne correspond pas aux pages existantes, vous pouvez toujours ouvrir un ticket. Vous pouvez soit choisir une page existante à proximité du lieu où le nouveau contenu doit aller et classer le problème à partir de cette page, soit aller directement à [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) et déposer le problème à partir de là. ### Comment créer de bons tickets @@ -104,22 +104,22 @@ Pour nous assurer que nous comprenons votre problème et pouvons y donner suite, Pour les problèmes de grande envergure, décomposez-les en problèmes plus petits. Par exemple, "Corriger les docs de sécurité" n'est pas une question pouvant donner lieu à une action, mais "Ajouter des détails au thème 'Restreindre l'accès au réseau'" pourrait l'être. -- Si le problème concerne un autre problème ou une demande d'extraction, vous pouvez y faire référence soit par son URL complète, soit par le problème ou par un numéro de demande d'extraction précédé du caractère "#". +- Si la demande concerne un autre problème ou une pull request, vous pouvez y faire référence soit par son URL complète, soit par le problème ou par un numéro de demande d'extraction précédé du caractère "#". Par exemple, `Introduced by #987654`. - Soyez respectueux et restez constructif. - Par exemple, "La documentation sur X est nulle" n'est pas utile ou avec des commentaires exploitables. - Le [Code de conduite](/community/code-of-conduct/) s'applique également aux interactions sur les référentiels Kubernetes GitHub. + Par exemple, "La documentation sur X est nulle" n'est ni utile ni constructif. + Le [Code de conduite](/community/code-of-conduct/) s'applique également aux interactions sur les dépôts Kubernetes GitHub. ## Participer aux discussions SIG Docs L'équipe SIG Docs communique à l'aide des mécanismes suivants: -- [Rejoindre l'instance Slack de Kubernetes](http://slack.k8s.io/), puis rejoignez `#sig-docs` canal, où nous discutons des problèmes de documentation en temps réel. +- [Rejoindre l'instance Slack de Kubernetes](http://slack.k8s.io/), puis rejoignez le canal `#sig-docs`, où nous discutons des problèmes de documentation en temps réel. Présentez-vous quand vous arrivez! - [Rejoignez la liste de diffusion `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), où des discussions plus larges ont lieu et où les décisions officielles sont enregistrées. -- Participer à l'[hebdomadaire SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) réunion vidéo, qui est annoncée sur le canal Slack et la liste de diffusion. +- Participer à l'[hebdomadaire SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs), une réunion vidéo, qui est annoncée sur le canal Slack et la liste de diffusion. Actuellement, ces réunions ont lieu sur Zoom. - Vous devez donc télécharger le logiciel [Zoom client](https://zoom.us/download) ou composez en utilisant un téléphone. + Vous devez donc télécharger le logiciel [Zoom](https://zoom.us/download) ou rejoindre la conférence par téléphone. - Pour les utilisateurs francophones, vous pouvez également rejoindre le canal Slack [`#kubernetes-docs-fr`](https://kubernetes.slack.com/messages/CG838BFT9/), où nous discutons des traductions en Français de la documentation de Kubernetes. {{< note >}} @@ -134,8 +134,8 @@ Pour les besoins de cette rubrique, vous n'avez pas besoin de tout savoir à leu Quand vous passerez au [Guide des contributeurs docs intermédiaires](/docs/contribute/intermediate/), vous aurez besoin de plus de connaissances en terminologie Git. {{< note >}} -**Développeurs de code Kubernetes**: Si vous documentez une nouvelle fonctionnalité pour une prochaine version de Kubernetes, votre processus est un peu différent. -Voir [Documenter une fonctionnalité](/docs/contribute/intermediate/#sig-members-documenting-new-features) pour des directives de processus et des informations sur les délais. +**Développeurs Kubernetes**: Si vous documentez une nouvelle fonctionnalité pour une prochaine version de Kubernetes, votre processus est un peu différent. +Voir [Documenter une fonctionnalité](/docs/contribute/intermediate/#sig-members-documenting-new-features) pour des instructions sur le processus et pour des des informations à propos des échéances. {{< /note >}} ### Signer le CLA @@ -146,15 +146,15 @@ Ne vous inquiétez pas, cela ne prend pas longtemps ! ### Trouvez quelque chose sur lequel travailler Si vous voyez quelque chose que vous souhaitez réparer immédiatement, suivez simplement les instructions ci-dessous. -Vous n'avez pas besoin de [ouvrir un ticket](#file-actionable-issues) (bien que vous puissiez certainement). +Vous n'avez pas besoin d'[ouvrir un ticket](#file-actionable-issues) (bien que vous puissiez aussi). Si vous souhaitez commencer par trouver un problème existant sur lequel travailler, allez à [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) et chercher des problèmes avec le label `good first issue` (vous pouvez utiliser [ce](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) raccourci). -Lisez tous les commentaires et assurez-vous qu’il n’ya pas de requête ouverte contre le problème et que personne n’a laissé de commentaire indiquant qu’ils travaillent sur le problème récemment (une règle de 3 jours est une bonne règle). +Lisez tous les commentaires et assurez-vous qu’il n’y a pas de pull request existante pour ce même problème et que personne n’a laissé de commentaire indiquant qu’ils travaillent sur le problème récemment (une durée de 3 jours est une bonne règle). Laissez un commentaire indiquant que vous souhaitez travailler sur la question. ### Choisissez quelle branche Git utiliser -L'aspect le plus important de la soumission d'une pull requests c'est choisir la branche sur laquelle baser votre travail. +L'aspect le plus important de la soumission d'une pull request c'est choisir la branche sur laquelle baser votre travail. Utilisez ces directives pour prendre la décision: - Utilisez `master` pour résoudre les problèmes de contenu déjà publié ou pour améliorer le contenu déjà existant. @@ -165,17 +165,17 @@ Si vous ne savez toujours pas quelle branche choisir, demandez `#sig-docs` sur S ### Soumettre une pull request -Suivez ces étapes pour soumettre une demande d'extraction afin d'améliorer la documentation de Kubernetes. +Suivez ces étapes pour soumettre une pull request afin d'améliorer la documentation de Kubernetes. 1. Sur la page où vous voyez le problème, cliquez sur l'icône en forme de crayon en haut à gauche. Une nouvelle page apparaît avec un texte d'aide. 2. Cliquez sur le premier bouton bleu, qui a le texte **Edit <page name>**. - Si vous n'avez jamais créé de fork du référentiel de documentation Kubernetes, vous êtes invité à le faire. + Si vous n'avez jamais créé de fork du dépôt de documentation Kubernetes, vous êtes invité à le faire. Créez le fork sous votre nom d'utilisateur GitHub, plutôt que celui d'une autre organisation dont vous pourriez être membre. Le fork a généralement une URL telle que `https://github.com//website`, à moins que vous n'ayez déjà un dépôt avec un nom en conflit (website). - La raison pour laquelle vous êtes invité à créer un fork est que vous n'avez pas le droit de pousser une branche directement dans le référentiel définitif de Kubernetes. + La raison pour laquelle vous êtes invité à créer un fork est que vous n'avez pas le droit de pousser une branche directement vers le dépôt Kubernetes officiel. 3. L'éditeur GitHub Markdown apparaît avec le fichier source Markdown chargé. Faites vos changements. @@ -184,14 +184,14 @@ Suivez ces étapes pour soumettre une demande d'extraction afin d'améliorer la Le deuxième champ est facultatif, mais peut inclure plus de détails si nécessaire. {{< note >}} - Ne pas inclure de références à d’autres GitHub issues ou pull requests dans votre message de commit. + Ne pas inclure de références à d’autres demandes GitHub ou pull requests dans votre message de commit. Vous pouvez les ajouter ultérieurement à la description de la demande d'extraction. {{< /note >}} Cliquez sur **Propose file change**. - La modification est enregistrée en tant que commit dans une nouvelle branche de votre branche, qui porte automatiquement le nom suivant: `patch-1`. + La modification est enregistrée en tant que commit dans une nouvelle branche de votre fork, qui porte automatiquement le nom suivant: `patch-1`. -4. L’écran suivant récapitule les modifications que vous avez apportées en comparant votre nouvelle branche ( **head fork** et **compare** boîtes de sélection) à l'état actuel de **base fork** et **base** branche (`master` sur le dépôt `kubernetes/website` par défaut). +4. L’écran suivant récapitule les modifications que vous avez apportées en comparant votre nouvelle branche (les boîtes de sélection **head fork** et **compare**) à l'état actuel de **base fork** et **base** branche (`master` sur le dépôt `kubernetes/website` par défaut). Vous pouvez modifier n'importe quelle boîte de sélection, mais ne le faites pas maintenant. Jetez un coup d’œil à la visionneuse de différences en bas de l’écran et, si tout se présente bien, cliquez sur **Create pull request**. @@ -200,40 +200,40 @@ Suivez ces étapes pour soumettre une demande d'extraction afin d'améliorer la Le site Web GitHub vous invitera à créer la pull request s'il détecte que vous avez poussé une nouvelle branche vers votre fork. {{< /note >}} -5. L'écran **Open a pull request** apparait. - Le sujet de la demande d'extraction est identique au résumé de validation, mais vous pouvez le modifier si nécessaire. - Le corps est rempli par votre message de validation étendu (s'il est présent) et par un template. - Lisez le template et remplissez les informations demandées, puis supprimez le texte supplémentaire. - Laissez la case à cocher selectionnée **Allow edits from maintainers**. +5. L'écran **Open a pull request** apparaît. + Le sujet de la pull request est identique au message du commit, mais vous pouvez le modifier si nécessaire. + Le corps est rempli par le reste du message du commit (s'il est présent) et par un modèle. + Lisez le modèle et remplissez les informations demandées, puis supprimez le texte supplémentaire. + Laissez la case à cocher sélectionnée **Allow edits from maintainers**. Cliquez sur **Create pull request**. Toutes nos félicitations ! Votre pull request est disponible dans [Pull requests](https://github.com/kubernetes/website/pulls). Après quelques minutes, vous pouvez prévisualiser le site Web contenant les modifications apportées par votre PR. - Aller sur l'onglet **Conversation** de votre PR et cliquez sur le lien **Details** pour le test `deploy/netlify`, près du bas de la page. - Il s'ouvre dans la même fenêtre de navigateur par défaut. + Aller sur l'onglet **Conversation** de votre PR et cliquez sur le lien **Details** pour le déploiement `deploy/netlify`, près du bas de la page. + Il s'ouvrira dans la même fenêtre. 6. Attendez la revue. En général, les relecteurs sont suggérés par le `k8s-ci-robot`. - Si un réviseur vous demande d’apporter des modifications, vous pouvez aller à l'onglet **Files changed** et cliquez sur l'icône en forme de crayon sur les fichiers modifiés par la demande d'extraction. + Si un relecteur vous demande d’apporter des modifications, vous pouvez aller à l'onglet **Files changed** et cliquez sur l'icône en forme de crayon sur les fichiers modifiés par la pull request. Lorsque vous enregistrez le fichier modifié, un nouveau commit est créé dans la branche surveillée par la pull request. -7. Si votre modification est acceptée, un relecteur merge votre pull request, et le changement est en direct sur le site Web de Kubernetes quelques minutes plus tard. +7. Si votre modification est acceptée, un relecteur fusionnera votre pull request, et le changement sera visible sur le site Web de Kubernetes quelques minutes plus tard. -Ce n’est qu’un moyen de soumettre une pull request. +Ce n’est qu’un des différents moyens de soumettre une pull request. Si vous êtes déjà un utilisateur expérimenté de Git et GitHub, vous pouvez utiliser une interface graphique locale ou un client Git en ligne de commande au lieu d'utiliser l'interface utilisateur de GitHub. Quelques notions de base sur l’utilisation du client Git en ligne de commande sont abordées dans la section [intermédiaire](/docs/contribute/intermediate/) du guide des contributeurs. ## Relecture des pull requests de documentation Les personnes qui ne sont pas encore des approbateurs ou des relecteurs peuvent quand même relire des pull requests. -Les avis ne sont pas considérés comme "contraignants", ce qui signifie que votre avis seul ne causera pas un merge de la pull request. +Leurs avis ne font pas autorité, ce qui signifie que ces avis seuls ne causeront pas une fusion de la pull request. Cependant, cela peut toujours être utile. -Même si vous ne laissez aucun commentaire, vous pourrez avoir une idée des conventions pull request, de l'étiquette des interactions entre les différents membres et ainsi vous habituer au workflow. +Même si vous ne laissez aucun commentaire, vous pourrez avoir une idée des conventions des pull requests, de l'étiquette des interactions entre les différents membres et ainsi vous habituer au processus. -1. Aller à [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). - Vous voyez une liste de toutes les pull request ouvertes sur le Kubernetes website et la documentation. +1. Allez à [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). + Vous verrez une liste de toutes les pull requests ouvertes visant site web Kubernetes et la documentation. 2. Par défaut, le seul filtre appliqué est `open`, donc vous ne voyez pas les pull requests qui ont déjà été fermées ou fusionnées. C'est une bonne idée d'appliquer le filtre `cncf-cla: yes`, et pour votre premier examen, c'est une bonne idée d'ajouter `size/S` ou `size/XS`. @@ -241,7 +241,7 @@ Même si vous ne laissez aucun commentaire, vous pourrez avoir une idée des con Vous pouvez appliquer des filtres en utilisation les boites de sélection en haut de la page, ou utilisez directement [ce raccourci](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) pour voir seulement les petites PRs. Tous les filtres sont combinés (opérateur `AND`), de sorte que vous ne pouvez pas rechercher `size/XS` et `size/S` dans la même requête. -3. Aller à l'onglet **Files changed**. +3. Allez à l'onglet **Files changed**. Parcourez les modifications introduites dans la PR et, le cas échéant, les problèmes liés. Si vous constatez un problème ou des améliorations à apporter, passez la souris sur la ligne et cliquez sur le symbole `+` qui apparaît. @@ -256,19 +256,19 @@ Merci d'avoir commenté une pull request ! Lorsque vous débutez dans le projet, il est judicieux de demander votre avis sur votre pull request. Le canal Slack `#sig-docs` est un excellent endroit pour faire cela. -## Écrire un article de blog +## Écrire un article dans le blog -Tout le monde peut écrire un article de blog et le soumettre pour examen. -Les articles de blogs ne doivent pas être de nature commerciale et doivent comporter un contenu qui s’appliquera de manière large à la communauté Kubernetes. +Tout le monde peut écrire un article et le soumettre pour examen. +Les articles ne doivent pas être de nature commerciale et doivent comporter un contenu qui s’appliquera de manière large à la communauté Kubernetes. -Pour soumettre un article de blog, vous pouvez soit le soumettre en utilisant le [Formulaire de soumission de blog Kubernetes](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform), soit en suivant les étapes ci-dessous : +Pour soumettre un article, vous pouvez soit le soumettre en utilisant le [Formulaire de soumission de blog Kubernetes](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform), soit en suivant les étapes ci-dessous : 1. [Signez le CLA](#sign-the-cla) si vous ne l'avez pas encore fait. -2. Consultez le format Markdown pour les articles de blog existants dans le [dépôt du website](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts). -3. Rédigez votre article de blog dans un éditeur de texte de votre choix. +2. Consultez le format Markdown pour les articles de blog existants dans le [dépôt du site web](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts). +3. Rédigez votre article dans l'éditeur de texte de votre choix. 4. Sur le même lien à partir de l'étape 2, cliquez sur le bouton **Create new file**. Collez votre contenu dans l'éditeur. - Nommez le fichier pour qu'il corresponde au titre proposé de l'article de blog, mais ne mettez pas la date dans le nom du fichier. + Nommez le fichier pour qu'il corresponde au titre proposé de l'article, mais ne mettez pas la date dans le nom du fichier. Les réviseurs de blog travailleront avec vous sur le nom de fichier final et la date de publication du blog. 1. Lorsque vous enregistrez le fichier, GitHub vous guidera à travers le processus d'une pull request. 1. Un critique de publication de blog examinera votre soumission et travaillera avec vous sur les commentaires et les détails finaux. @@ -280,7 +280,7 @@ Des études de cas montrent comment les entreprises utilisent Kubernetes pour r Elles sont écrites en collaboration avec l'équipe marketing de Kubernetes, qui est gérée par la CNCF. Regardez la source des [études de cas existantes](https://github.com/kubernetes/website/tree/master/content/en/case-studies). -Utilisez le [Formulaire de soumission d'étude de cas Kubernetes](https://www.cncf.io/people/end-user-community/) soumettre votre proposition. +Utilisez le [Formulaire de soumission d'étude de cas Kubernetes](https://www.cncf.io/people/end-user-community/) pour soumettre votre proposition. {{% /capture %}} diff --git a/content/fr/docs/home/_index.md b/content/fr/docs/home/_index.md index de5685d82b..584ad33232 100644 --- a/content/fr/docs/home/_index.md +++ b/content/fr/docs/home/_index.md @@ -7,7 +7,7 @@ noedit: true cid: docsHome layout: docsportal_home class: gridPage -linkTitle: "Home" +linkTitle: "Accueil" main_menu: true weight: 10 hide_feedback: true @@ -47,7 +47,7 @@ cards: button_path: /docs/reference - name: contribute title: Contribuer à la documentation - description: Tout le monde peut contribuer, que vous soyez nouveau dans le projet ou experimenté. + description: Tout le monde peut contribuer, que vous soyez nouveau dans le projet ou expérimenté. button: Contribuer à la documentation button_path: /docs/contribute - name: download diff --git a/content/fr/docs/setup/_index.md b/content/fr/docs/setup/_index.md index 3686f9dcba..42f35c6d77 100644 --- a/content/fr/docs/setup/_index.md +++ b/content/fr/docs/setup/_index.md @@ -6,7 +6,7 @@ reviewers: - awkif - yastij no_issue: true -title: Setup +title: Installation description: Panorama de solution Kubernetes main_menu: true weight: 30 @@ -16,11 +16,9 @@ content_template: templates/concept Utilisez cette page pour trouver le type de solution qui correspond le mieux à vos besoins. -Le choix de l'emplacement de Kubernetes dépend des ressources dont vous disposez -et de la flexibilité dont vous avez besoin. Vous pouvez executer Kubernetes presque partout, -de votre ordinateur portable aux machines virtuelles d'un fournisseur de cloud jusqu'à un rack de serveurs en bare metal. -Vous pouvez également mettre en place un cluster entièrement géré en exécutant une seule commande ou bien créer -votre propre cluster personnalisé sur vos serveurs bare-metal. +Le choix de distribution Kubernetes dépend des ressources dont vous disposez et de la flexibilité dont vous avez besoin. +Vous pouvez exécuter Kubernetes presque partout, de votre ordinateur portable aux machines virtuelles d'un fournisseur de cloud jusqu'à un rack de serveurs en bare metal. +Vous pouvez également mettre en place un cluster entièrement géré en exécutant une seule commande ou bien créer votre propre cluster personnalisé sur vos serveurs bare-metal. {{% /capture %}} @@ -82,7 +80,7 @@ Choisissez une [solution clé en main sur site] (/docs/setup/pick-right-solution ## Solutions personnalisées -Les solutions personnalisées vous offrent le maximum de liberté sur vos clusters, mais elles nécessitent le plus +Les solutions personnalisées vous offrent le maximum de liberté sur vos clusters, mais elles nécessitent plus d'expertise. Ces solutions vont du bare-metal aux fournisseurs de cloud sur différents systèmes d'exploitation. @@ -91,5 +89,5 @@ Choisissez une [solution personnalisée] (/docs/setup/pick-right-solution/#custo {{% /capture %}} {{% capture whatsnext %}} -Allez à [Choisir la bonne solution] (/docs/setup/pick-right-solution/) pour une list complète de solutions. +Allez à [Choisir la bonne solution] (/docs/setup/pick-right-solution/) pour une liste complète de solutions. {{% /capture %}} diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index f1003b6d64..294452c937 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -8,7 +8,7 @@ menu: title: "Démarrer" weight: 10 post: > -

Prêt à vous salir les mains ? Créez un cluster Kubernetes simple qui exécute "Hello World" pour Node.js.

>. +

Prêt à mettre les mains dans le cambouis ? Créez un cluster Kubernetes simple qui exécute "Hello World" avec Node.js.

>. card: name: tutorials weight: 10 @@ -120,11 +120,10 @@ Pod utilise un conteneur basé sur l'image Docker fournie. ## Créer un service -Par défaut, le Pod n'est accessible que par son adresse IP interne dans le -Kubernetes cluster. -Pour rendre le conteneur `hello-node` accessible de l'extérieur du réseau virtuel Kubernetes, vous devez exposer le Pod comme un [*Service*](/docs/concepts/services-networking/service/) Kubernetes. +Par défaut, le Pod n'est accessible que par son adresse IP interne dans le cluster Kubernetes. +Pour rendre le conteneur `hello-node` accessible depuis l'extérieur du réseau virtuel Kubernetes, vous devez exposer le Pod comme un [*Service*](/docs/concepts/services-networking/service/) Kubernetes. -1. Exposez le Pod à l'Internet public en utilisant la commande `kubectl expose` : +1. Exposez le Pod à internet en utilisant la commande `kubectl expose` : ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 @@ -153,7 +152,7 @@ Pour rendre le conteneur `hello-node` accessible de l'extérieur du réseau virt 3. Exécutez la commande suivante : ```shell - minikube service hello-node hello-node + minikube service hello-node ``` 4. Environnement Katacoda seulement : Cliquez sur le signe plus, puis cliquez sur **Sélectionner le port pour afficher sur l'hôte 1**. @@ -162,11 +161,11 @@ Pour rendre le conteneur `hello-node` accessible de l'extérieur du réseau virt Cela ouvre une fenêtre de navigateur qui sert votre application et affiche le message `Hello World`. -## Activer les addons +## Activer les extensions -Minikube dispose d'un ensemble d'addons intégrés qui peuvent être activés, désactivés et ouverts dans l'environnement Kubernetes local. +Minikube dispose d'un ensemble d'extensions intégrées qui peuvent être activées, désactivées et ouvertes dans l'environnement Kubernetes local. -1. Énumérer les addons actuellement pris en charge : +1. Énumérer les extensions actuellement pris en charge : ```shell minikube addons list @@ -192,7 +191,7 @@ Minikube dispose d'un ensemble d'addons intégrés qui peuvent être activés, d storage-provisioner: enabled ``` -2. Activez un addon, par exemple, `heapster` : +2. Activez une extension, par exemple, `heapster` : ```shell minikube addons enable heapster @@ -256,7 +255,7 @@ Si nécessaire, arrêtez la machine virtuelle Minikube (VM) : minikube stop ``` -Si nécessaire, effacez le Minikube VM : +Si nécessaire, effacez la VM Minikube : ```shell minikube delete