New Crowdin updates

docs/guides/rocky_insights/blogs/good_docs.de.md

@@ -0,0 +1,88 @@
+---
+title: Gute Dokumentation — die Sicht eines Übersetzers
+author: Ganna Zhyrnova
+contributors: Steven Spencer
+---
+
+## Introduktion
+
+Übersetzer bieten wertvolle Einblicke in das Verfassen klarer und prägnanter Dokumentationen. Sie wissen besser als die meisten anderen, was sich nicht gut übersetzen lässt und was einen Leser verwirrt. In diesem Dokument werden einige dieser Probleme untersucht und bewährte Vorgehensweisen für die Dokumentations-Erstellung hervorgehoben.
+
+### Über den Autor
+
+Mithilfe der Softwaredokumentation können Benutzer besser verstehen, wie sie eine bestimmte Software effektiv nutzen können. Sie müssen verstehen, was sie am Ende haben und welche Vorteile sie haben werden. Gleichzeitig bedeutet das Erstellen einer Dokumentation, dass Sie diese nicht nur für sich selbst, sondern auch für Ihr Netzwerk und für andere Personen erstellen, die sie möglicherweise lesen. Andere Personen stammen möglicherweise nicht aus englischsprachigen Ländern. Das bedeutet, dass Englisch für sie nicht ihre Muttersprache ist. Befolgen Sie daher diese Grundregeln, um Ihre Dokumentation für _alle_ Benutzer lesbarer zu machen.
+
+## Verständliche Sprache verwenden
+
+Es ist grundsätzlich nicht ersichtlich, wer die Nutzer der Dokumentation sind. Ob der Benutzer sich auf diesem Gebiet auskennt oder nicht, ob er ein erfahrener Entwickler oder ein Anfänger ist. Einfache Sprache bedeutet klare, prägnante Kommunikation, die für die Zielgruppe auf den ersten Blick leicht verständlich ist. Vermeiden Sie Fachjargon, übermäßig technische Begriffe und komplexe Satzstrukturen und verwenden Sie stattdessen eine einfachere, klar strukturierte Sprache. Ziel ist es, sicherzustellen, dass die Botschaft für ein breites Publikum zugänglich und verständlich ist, unabhängig von dessen Hintergrund oder Leseniveau. Dies kann häufig durch Vereinfachung der Syntax von Sätzen oder Befehlen auf eine einfachere Form erreicht werden.
+
+## Vermeiden Sie Redewendungen, Fachjargon, Akronyme und Abkürzungen
+
+Redewendungen, Fachjargon, Abkürzungen und Akronyme können für Leser, die damit nicht vertraut sind, verwirrend sein. Dies gilt insbesondere für Nicht-Muttersprachler, neue Mitarbeiter oder Personen, die mit Ihrer spezifischen Branche nicht vertraut sind.
+
+**Redewendungen, Idioms** sind oft kulturspezifisch und können für internationale Leser schwer verständlich sein.  
+**Jargon** umfasst Fachbegriffe, die nur Experten auf einem bestimmten Gebiet verstehen.  
+**Kontraktionen** ersetzen englische Wörter durch Abkürzungen, aber diese gibt es nicht immer in allen Sprachen, was die Übersetzung erschwert.  
+**Akronyme** können mehrdeutig sein, insbesondere wenn sie bei ihrer Verwendung nicht definiert sind.
+
+Ein Beispiel:
+
+❌ "Once you’ve got the hang of the dashboard, the rest is a piece of cake." In diesem Fall verwendet der Autor sowohl eine Kontraktion, Slang als auch eine Redewendung.
+
+✅ "Once you have learned how to use the dashboard, the rest is easy." Durch Ersetzen der Kontraktion, des Slangs und der Redewendung durch die jeweils zugehörigen Wörter wird die Bedeutung klar.
+
+Bildliche Ausdrücke, wie etwa Redewendungen, sind oft schwer zu übersetzen. Technische Redakteure oder Übersetzer haben möglicherweise Schwierigkeiten, dieselbe Bedeutung in anderen Sprachen wiederzugeben.
+
+Beispiel:
+
+❌ "Let’s touch base next week to circle back on the open tickets."
+
+✅ "Let us meet next week to review the unresolved support requests."
+
+Fachjargon und Abkürzungen können – sogar innerhalb derselben Organisation – verwirrend sein, wenn ihre Bedeutung nicht allgemein bekannt ist.
+
+Beispiel:
+
+❌ "Upload the CSV to the CMS and tag it according to SOPs."
+
+✅ "Upload the CSV (Comma-Separated Values file) to the content management system and label it according to the standard operating procedures."
+
+Hinweis: Wenn Sie Akronyme verwenden möchten, definieren Sie diese immer gleich beim ersten Mal: „Customer Relationship Management (CRM)-System“.
+
+Durch die Vermeidung von Redewendungen und unnötigem Fachjargon wird die Bedeutung Ihres Dokuments klarer. Das Ersetzen von Kontraktionen durch die entsprechende Wörter, die sie darstellen, erleichtert die Übersetzung in alle Sprachen. Ihr Dokument ist für den Leser am verständlichsten, wenn Sie Akronyme ersetzen oder definieren.
+
+## Tätigkeitsform (Aktiv) verwenden
+
+Die aktive Form betont, wer die Handlung ausführt, und macht deutlich, wer oder was für die Handlung des Verbs verantwortlich ist.
+
+Beispiel:
+
+The system opens the dialog where you need to complete the form.
+
+Bitte verzichten Sie auf die Verwendung der komplexen Form, da diese für die Leser verwirrend sein kann.
+
+Weitere Informationen zur Verwendung der Aktivform und ihrer Bedeutung finden Sie in [dieser Meinung](active_voice.md) und [dieser externen Quelle](https://developers.google.com/tech-writing/one/active-voice).
+
+## Spezifische Schritte
+
+Wenn die Dokumentation bestimmte Schritte enthält, trennen Sie diese voneinander.
+
+Zum Beispiel:
+
+Step 1 - Go to the section  
+Step 2 - Click the button  
+Step 3 - Complete the form  
+...  
+Step N - save changes
+
+## Screenshots wenn nötig
+
+Verwenden Sie bei Bedarf geeignete Screenshots. Das bedeutet, dass Sie nicht überall Screenshots hinzufügen müssen, sondern nur an den Stellen, an denen zusätzliche Erklärungen erforderlich sind.
+
+## Verwenden Sie Beispiele
+
+Wenn Sie ein Formular ausfüllen müssen, geben Sie Beispiele dafür, wie Benutzer es ausfüllen können. Erwähnen Sie Einschränkungen, falls vorhanden.
+
+## Zusammenfassung
+
+Beim Verfassen einer guten Dokumentation geht es nicht nur darum, dass sie technisch korrekt ist, sondern auch darum, dass sie für den Leser sofort verständlich ist. Dies ist besonders wichtig, wenn ein technisches Dokument in andere Sprachen übersetzt werden muss. In diesem Dokument wollte der Autor bestimmte Techniken zum Schreiben guter und klarer Dokumentationen hervorheben.

docs/guides/rocky_insights/blogs/good_docs.fr.md

@@ -0,0 +1,88 @@
+---
+title: Good Docs – le point de vue d'une traductrice
+author: Ganna Zhyrnova
+contributors: Steven Spencer
+---
+
+## Introduction
+
+Les traducteurs fournissent des renseignements précieux pour rédiger une documentation claire et concise. Ils savent mieux que quiconque ce qui ne se traduit pas bien et ce qui embrouille le lecteur. Ce document examine certains de ces problèmes et met en évidence les meilleures pratiques en matière de création de documentation.
+
+### Du Point de vue de l'Auteur
+
+La documentation de logiciel aide les utilisateurs à comprendre comment utiliser efficacement un logiciel particulier. Ils doivent comprendre ce qu’ils obtiendront au bout du compte et quels avantages ils en tireront. En même temps, lorsque vous créez de la documentation, vous la créez non seulement pour vous-même, mais également pour votre réseau et d’autres personnes susceptibles de la lire. D’autres personnes peuvent ne pas être originaires de pays anglophones. Cela signifie que l'anglais n'est pas leur langue principale. Pour cette raison, suivez ces règles fondamentales pour rendre votre documentation plus lisible pour _tous_ les utilisateurs.
+
+## Utilisez un langage clair et simple
+
+Vous n'avez pas la moindre idée de qui est vraiment l'utilisateur de la doc. Peu importe que cet utilisateur soit familier avec le domaine, qu'il soit un développeur expérimenté ou un débutant. Un langage clair et concis est la base d'une communication que le public ciblé peut facilement comprendre dès la première lecture. Il évite le jargon, les termes techniques et les constructions syntaxiques complexes au profit d'un langage plus simple et d'une structure claire. L'objectif est de s'assurer que le message est accessible et compréhensible pour un large public, peu importe son parcours ou son niveau de préparation à la lecture. Cela peut souvent être réalisé en simplifiant la structure des phrases ou des commandes à leur forme la plus simple.
+
+## Évitez les expressions idiomatiques, le jargon, les acronymes et les abréviations
+
+Les expressions idiomatiques, le jargon, les abréviations et les acronymes peuvent être déroutants pour les lecteurs qui ne les connaissent pas, en particulier les locuteurs non natifs, les nouveaux employés ou les personnes externes à votre secteur d'activité spécifique.
+
+Les **idiomes** sont souvent propres à une certaine culture et peuvent être difficiles à comprendre pour les lecteurs internationaux.  
+Le **jargon** comprend des termes spécialisés que seuls les experts dans un domaine particulier peuvent bien saisir.  
+**Les abréviations** remplacent les mots en anglais par des formes abrégées, mais ces abréviations n'existent pas toujours dans toutes les langues, ce qui rend la traduction difficile.  
+**Les acronymes** peuvent être ambigus, surtout s'ils ne sont pas définis lors de leur première utilisation.
+
+Exemple :
+
+❌ "Once you’ve got the hang of the dashboard, the rest is a piece of cake." Ici, l'auteur utilise des abréviations, de l'argot et des expressions idiomatiques.
+
+✅ "Once you have learned how to use the dashboard, the rest is easy." En remplaçant les abréviations, l'argot et les idiomes par des mots associés à chacun d'eux, le sens devient plus clair.
+
+Les expressions figuratives, comme celles dans les idiomes, sont souvent difficiles à traduire. Les rédacteurs techniques ou les traducteurs peuvent avoir de la difficulté à transmettre le même sens dans d'autres langues.
+
+Exemple :
+
+❌ "Let’s touch base next week to circle back on the open tickets."
+
+✅ "Let us meet next week to review the unresolved support requests."
+
+Le jargon et les acronymes peuvent être source de confusion, même au sein d'une même organisation, si leur signification n'est pas universellement connue.
+
+Exemple :
+
+❌ "Upload the CSV to the CMS and tag it according to SOPs."
+
+✅ "Upload the CSV (Comma-Separated Values file) to the content management system and label it according to the standard operating procedures."
+
+Remarque : si vous souhaitez utiliser des acronymes, définissez-les toujours la première fois : « Système de gestion de la relation client (CRM) ».
+
+En éliminant les expressions idiomatiques et le jargon inutile, le sens de votre document devient plus clair. Remplacer les contractions par les mots qu'elles représentent signifie que les efforts de traduction dans toutes les langues sont plus faciles. Votre document est plus compréhensible pour le lecteur lorsque vous remplacez ou définissez des acronymes.
+
+## Utilisez la voix active
+
+La voix active met l'accent sur l'auteur de l'action, indiquant clairement qui ou quoi est responsable de l'action du verbe.
+
+Exemple :
+
+Le système ouvre la boîte de dialogue dans laquelle vous devez remplir le formulaire.
+
+Veuillez éviter d'utiliser la forme complexe, car elle peut être déroutante pour les lecteurs.
+
+Pour en savoir plus sur l’utilisation de la voix active et l’importance de son utilisation, consultez [cet avis](active_voice.md) et [cette source externe](https://developers.google.com/tech-writing/one/active-voice).
+
+## Étapes spécifiques
+
+Si vous avez des étapes spécifiques dans la documentation, séparez-les les unes des autres.
+
+Par exemple :
+
+Step 1 - Go to the section  
+Step 2 - Click the button  
+Step 3 - Complete the form  
+...  
+Étape N – enregistrement des modifications
+
+## Captures d'écran si nécessaires
+
+Utilisez des captures d'écran appropriées si nécessaire. Cela signifie que vous n'avez pas besoin d'ajouter des captures d'écran partout, seulement aux endroits où vous avez besoin d'explications supplémentaires.
+
+## Utilisez des exemples
+
+Si vous devez remplir le formulaire, donnez des exemples de la façon dont les utilisateurs peuvent le remplir. Mentionnez les limites s'ils en ont.
+
+## Conclusion
+
+Rédiger une bonne documentation ne consiste pas seulement à la rendre techniquement précise, il est également très important de la rendre immédiatement compréhensible pour le lecteur. Ceci est particulièrement important lorsqu'un document technique doit être traduit dans d'autres langues. Dans ce document, l'intention de l'auteur était de mettre en évidence des techniques spécifiques pour rédiger une documentation de qualité et claire.

docs/guides/rocky_insights/blogs/good_docs.it.md

@@ -0,0 +1,88 @@
+---
+title: Good Docs - Il punto di vista di un traduttore
+author: Ganna Zhyrnova
+contributors: Steven Spencer
+---
+
+## Introduzione
+
+I traduttori forniscono indicazioni preziose per la stesura di una documentazione chiara e concisa. Sanno cosa non si traduce bene e cosa confonde il lettore meglio di chiunque altro. Questo documento esamina alcuni di questi aspetti ed evidenzia le migliori pratiche per la stesura dei documenti.
+
+### Dall'autore
+
+La documentazione del software aiuta gli utenti a capire come utilizzare efficacemente un determinato software. Devono capire cosa otterranno alla fine e quali vantaggi avranno. Allo stesso tempo, quando create una documentazione, significa crearla non solo per voi stessi, ma anche per la vostra rete e per le altre persone che potrebbero leggerla. Gli altri utenti potrebbero non provenire da paesi anglofoni. Ciò significa che per loro l'inglese non è la lingua principale. Proprio per questo motivo, seguite queste regole di base per rendere la documentazione più leggibile a _tutti_ gli utenti.
+
+## Uso di un linguaggio semplice
+
+In linea di principio, non si ha idea di chi siano i fruitori della documentazione. Se l'utente abbia o meno familiarità con questo ambito, che sia uno sviluppatore esperto o un principiante. Un linguaggio semplice sta a significare  una comunicazione chiara, concisa e di facile comprensione per il pubblico a cui è destinata la prima volta che la incontra. E' da evitare i termini gergali, quelli troppo tecnici e frasi con strutture complesse, a favore di un linguaggio più semplice e con un'organizzazione chiara. L'obiettivo è garantire che il messaggio sia accessibile e comprensibile a un ampio pubblico, indipendentemente dal suo background o dal suo livello di lettura. Spesso è possibile farlo semplificando la sintassi delle frase o i comandi fino ad una forma più elementare.
+
+## Evitare espressioni idiomatiche, gergo, acronimi e contrazioni.
+
+Idiomi, gergo, contrazioni e acronimi possono confondere i lettori che non li conoscono, in particolare coloro che non sono madrelingua, i nuovi dipendenti o tutti coloro che estranei al vostro settore specifico.
+
+Gli **idiomi** sono spesso specifici di una determinata cultura e possono essere difficili da comprendere per i lettori internazionali.  
+Il **gergo** comprende termini specialistici che solo gli esperti di un settore possono riconoscere.  
+Le **contrazioni** sostituiscono le parole della lingua inglese con scorciatoie, che però non sempre esistono in tutte le lingue, rendendo difficile la traduzione.  
+Gli **acronimi** possono essere ambigui, soprattutto se non vengono definiti al momento del loro utilizzo.
+
+Esempio:
+
+❌ “Una volta presa confidenza con il cruscotto, il resto è un gioco da ragazzi”. In questo caso, l'autore utilizza sia una contrazione, sia uno slang, sia un idioma.
+
+✅ “Una volta imparato a usare il cruscotto, il resto è facile”. Sostituendo la contrazione, il gergo e l'idioma con le parole associate a ciascuno di essi, il significato è chiaro.
+
+Il linguaggio figurato, come i modi di dire, spesso non si traduce bene. I redattori tecnici o i traduttori potrebbero avere difficoltà a trasmettere lo stesso significato in altre lingue.
+
+Esempio:
+
+❌ “Ci sentiamo la prossima settimana per fare il punto sui ticket aperti”.
+
+✅ “Incontriamoci la prossima settimana per rivedere le richieste di supporto non risolte”.
+
+Il gergo e gli acronimi possono generare confusione, anche all'interno della stessa organizzazione, se il loro significato non è universalmente conosciuto.
+
+Esempio:
+
+❌ “Caricare il CSV nel CMS ed etichettarlo secondo le SOP”.
+
+✅ “Caricare il file CSV (Comma-Separated Values) nel Content Management System (CMS) ed etichettarlo secondo le procedure operative standard (SOP).”
+
+Nota: se si desidera utilizzare acronimi, definirli sempre la prima volta: “Content Management System (CRM)”.
+
+Eliminando i modi di dire e il gergo non necessario, il significato del documento diventa più chiaro. Sostituire le contrazioni con le parole che rappresentano significa facilitare gli sforzi di traduzione in tutte le lingue. Il documento è più comprensibile per il lettore quando si sostituiscono o si definiscono gli acronimi.
+
+## Uso della forma attiva
+
+La voce attiva enfatizza chi compie l'azione, rendendo chiaro chi o cosa è responsabile dell'azione del verbo.
+
+Esempio:
+
+Il sistema apre la finestra di dialogo in cui è necessario completare il modulo.
+
+Si prega di astenersi dall'utilizzare una forma complessa, in quanto può confondere i lettori.
+
+Per saperne di più sull'uso della forma attiva e sulla sua importanza, si veda [questa parere](active_voice.md) e [questa fonte esterna](https://developers.google.com/tech-writing/one/active-voice).
+
+## Dividere in step
+
+Se la documentazione contiene passaggi specifici, separateli l'uno dall'altro.
+
+Ad esempio:
+
+Passo 1 - Accedere alla sezione
+Passo 2 - Fare clic sul pulsante
+Passo 3 - Compilare il modulo
+...  
+Passo N - salvare le modifiche
+
+## Screenshot quando necessario
+
+Utilizzate screenshot corretti dove necessario. Ciò significa che non è necessario aggiungere screenshot ovunque, ma solo nei punti in cui è necessario fornire ulteriori spiegazioni.
+
+## Uso degli esempi
+
+Se è necessario compilare il modulo, fornire esempi di come gli utenti possono completarlo. Indicare le limitazioni, se ci sono.
+
+## Conclusione
+
+Scrivere una buona documentazione non significa solo renderla tecnicamente accurata, ma anche renderla immediatamente comprensibile al lettore. Questo è particolarmente importante quando un documento tecnico deve essere tradotto in altre lingue. In questo documento, l'autore intendeva mettere in evidenza le tecniche specifiche per scrivere una buona documentazione chiara.