diff --git a/docs/guides/backup/rsnapshot_backup.it.md b/docs/guides/backup/rsnapshot_backup.it.md index 2a0182064c..dcc146ea69 100644 --- a/docs/guides/backup/rsnapshot_backup.it.md +++ b/docs/guides/backup/rsnapshot_backup.it.md @@ -12,12 +12,12 @@ tags: ## Prerequisiti - * Saper installare repository e snapshot aggiuntivi dalla riga di comando - * Conoscere il montaggio di filesystem esterni al computer (unità esterna, filesystem remoto e così via) - * Saper usare un editor (qui si usa `vi`, ma si può usare il proprio editor preferito) - * Conoscere un po' di scripting BASH - * Saper modificare il crontab per l'utente root - * Conoscenza delle chiavi pubbliche e private SSH (solo se si intende eseguire backup remoti da un altro server) +- Saper installare repository e snapshot aggiuntivi dalla riga di comando +- Conoscere il montaggio di filesystem esterni al computer (unità esterna, filesystem remoto e così via) +- Saper usare un editor (qui si usa `vi`, ma si può usare il proprio editor preferito) +- Conoscere un po' di scripting BASH +- Saper modificare il crontab per l'utente root +- Conoscenza delle chiavi pubbliche e private SSH (solo se si intende eseguire backup remoti da un altro server) ## Introduzione @@ -227,7 +227,7 @@ Le versioni precedenti di _rsnapshot_ avevano `hourly, daily, monthly, yearly` m In questo esempio, non si eseguiranno altri incrementi oltre al backup notturno. Basta aggiungere un commento ad alfa e gamma. Una volta completato, il file di configurazione sarà: -``` +```text #retain alpha 6 retain beta 7 #retain gamma 4 @@ -268,7 +268,7 @@ Anche in questo caso non è necessario specificare la configurazione, ma è una Il risultato sarà simile a questo, mostrando cosa accadrà quando il backup verrà effettivamente eseguito: -``` +```bash echo 1441 > /var/run/rsnapshot.pid mkdir -m 0755 -p /mnt/backup/storage/beta.0/ /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded \ @@ -308,7 +308,7 @@ Se non avete mai eseguito questa operazione, scegliete vim.basic come editor o i Si intende impostare il backup in modo che venga eseguito automaticamente alle 23: 00, quindi si aggiungerà questo codice al crontab: -``` +```bash ## Running the backup at 11 PM 00 23 * * * /usr/bin/rsnapshot -c /etc/rsnapshot.conf beta` ``` @@ -325,9 +325,9 @@ Esecuzione di _rsnapshot_ da una macchina in remoto, in sede. L'esecuzione di qu In questo caso, è necessario installare _rsnapshot_ sul computer che esegue tutti i backup. Altre ipotesi sono: -* Che i server su cui si eseguirà il backup abbiano una regola del firewall che consenta alla macchina remota di accedere al server SSH -* Che ogni server di cui si intende eseguire il backup abbia installato una versione recente di `rsync`. Per i server Rocky Linux, eseguire `dnf install rsync` per aggiornare la versione di `rsync` del sistema. -* Che ci si sia connessi alla macchina come utente root, o che si sia eseguito `sudo -s` per passare all'utente root +- Che i server su cui si eseguirà il backup abbiano una regola del firewall che consenta alla macchina remota di accedere al server SSH +- Che ogni server di cui si intende eseguire il backup abbia installato una versione recente di `rsync`. Per i server Rocky Linux, eseguire `dnf install rsync` per aggiornare la versione di `rsync` del sistema. +- Che ci si sia connessi alla macchina come utente root, o che si sia eseguito `sudo -s` per passare all'utente root ## Chiavi Pubbliche e Private SSH @@ -367,7 +367,7 @@ Successivamente, si deve modificare il file rsnapshot_web.conf in modo che inclu Ecco un esempio di configurazione di web.ourdomain.com: -``` +```bash ### BACKUP POINTS / SCRIPTS ### backup root@web.ourourdomain.com:/etc/ web.ourourdomain.com/ backup root@web.ourourdomain.com:/var/www/ web.ourourdomain.com/ @@ -396,7 +396,7 @@ L'automazione dei backup per la versione per più macchine o server è leggermen Con il contenuto: -``` +```bash #!/bin/bash/ # script to run rsnapshot backups in succession /usr/bin/rsnapshot -c /etc/rsnapshot_web.conf beta @@ -414,7 +414,7 @@ Creare il crontab per root per eseguire lo script di backup: Aggiungere questa riga: -``` +```bash ## Running the backup at 11 PM 00 23 * * * /usr/local/sbin/backup_all ``` diff --git a/docs/guides/backup/rsnapshot_backup.uk.md b/docs/guides/backup/rsnapshot_backup.uk.md index 1fdc48e19f..2b62a4a5ab 100644 --- a/docs/guides/backup/rsnapshot_backup.uk.md +++ b/docs/guides/backup/rsnapshot_backup.uk.md @@ -12,12 +12,12 @@ tags: ## Передумови - * Знати, як інсталювати додаткові репозиторії та снепшоти з командного рядка - * Дізнатися про монтування файлових систем, зовнішніх по відношенню до вашої машини (зовнішній диск, віддалена файлова система тощо). - * Знати, як користуватися редактором (використовуючи `vi` тут, але ви можете використовувати свій улюблений редактор) - * Трохи знати сценарії BASH - * Знати, як змінити crontab для користувача root - * Знання відкритих і закритих ключів SSH (тільки якщо ви плануєте запускати віддалене резервне копіювання з іншого сервера) +- Знати, як інсталювати додаткові репозиторії та снепшоти з командного рядка +- Дізнатися про монтування файлових систем, зовнішніх по відношенню до вашої машини (зовнішній диск, віддалена файлова система тощо). +- Знати, як користуватися редактором (використовуючи `vi` тут, але ви можете використовувати свій улюблений редактор) +- Трохи знати сценарії BASH +- Знати, як змінити crontab для користувача root +- Знання відкритих і закритих ключів SSH (тільки якщо ви плануєте запускати віддалене резервне копіювання з іншого сервера) ## Вступ @@ -227,7 +227,7 @@ _rsnapshot_ використовує `rsync` і повністю написан У цьому прикладі ви не збираєтеся запускати жодних інших інкрементів, окрім нічного резервного копіювання. Просто додайте примітку до альфа- і гамма. Після завершення файл конфігурації матиме наступний вигляд: -``` +```text #retain alpha 6 retain beta 7 #retain gamma 4 @@ -268,7 +268,7 @@ retain beta 7 Котрий поверне щось подібне до цього, показуючи вам, що станеться, коли резервне копіювання фактично запуститься: -``` +```bash echo 1441 > /var/run/rsnapshot.pid mkdir -m 0755 -p /mnt/backup/storage/beta.0/ /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded \ @@ -308,7 +308,7 @@ touch /mnt/backup/storage/beta.0/ Ви збираєтеся налаштувати резервне копіювання на автоматичний запуск о 23:00, тому додайте це до crontab: -``` +```bash ## Running the backup at 11 PM 00 23 * * * /usr/bin/rsnapshot -c /etc/rsnapshot.conf beta` ``` @@ -325,9 +325,9 @@ touch /mnt/backup/storage/beta.0/ У цьому випадку ви захочете інсталювати _rsnapshot_ на машині, яка виконує всі резервні копії. Інші припущення: -* Що сервери, на які ви будете створювати резервні копії, мають правило брандмауера, яке дозволяє віддаленій машині підключитися до нього через SSH -* Що на кожному сервері, резервну копію якого ви збираєтеся, було встановлено останню версію `rsync`. Для серверів Rocky Linux запустіть `dnf install rsync`, щоб оновити версію `rsync` вашої системи. -* Що ви підключилися до комп’ютера як користувач root або ви запустили `sudo -s`, щоб переключитися на користувача root +- Що сервери, на які ви будете створювати резервні копії, мають правило брандмауера, яке дозволяє віддаленій машині підключитися до нього через SSH +- Що на кожному сервері, резервну копію якого ви збираєтеся, було встановлено останню версію `rsync`. Для серверів Rocky Linux запустіть `dnf install rsync`, щоб оновити версію `rsync` вашої системи. +- Що ви підключилися до комп’ютера як користувач root або ви запустили `sudo -s`, щоб переключитися на користувача root ## Відкриті або закриті ключі SSH @@ -367,7 +367,7 @@ touch /mnt/backup/storage/beta.0/ Ось приклад конфігурації web.ourdomain.com: -``` +```bash ### BACKUP POINTS / SCRIPTS ### backup root@web.ourourdomain.com:/etc/ web.ourourdomain.com/ backup root@web.ourourdomain.com:/var/www/ web.ourourdomain.com/ @@ -396,7 +396,7 @@ backup root@web.ourdomain.com:/root/ web.ourdomain.com/ Зі змістом: -``` +```bash #!/bin/bash/ # script to run rsnapshot backups in succession /usr/bin/rsnapshot -c /etc/rsnapshot_web.conf beta @@ -414,7 +414,7 @@ backup root@web.ourdomain.com:/root/ web.ourdomain.com/ І додайте цей рядок: -``` +```bash ## Running the backup at 11 PM 00 23 * * * /usr/local/sbin/backup_all ``` diff --git a/docs/guides/contribute/style_guide.it.md b/docs/guides/contribute/style_guide.it.md index 74627b121e..3b2161eb0d 100644 --- a/docs/guides/contribute/style_guide.it.md +++ b/docs/guides/contribute/style_guide.it.md @@ -19,16 +19,16 @@ tags: Questa guida delinea gli standard di stile in lingua inglese per **migliorare la leggibilità, evidenziare casi particolari** e **migliorare il lavoro di traduzione** della documentazione Rocky Linux. Per le domande sullo stile non trattate in questa guida, si prega di fare riferimento a quanto segue: -* [Dizionario Merriam Webster](https://www.merriam-webster.com/) -* [Chicago Manual of Style (CMOS), 17a ed.](https://www.chicagomanualofstyle.org/home.html) +- [Dizionario Merriam Webster](https://www.merriam-webster.com/) +- [Chicago Manual of Style (CMOS), 17a ed.](https://www.chicagomanualofstyle.org/home.html) ### Contribuire Per una comprensione più completa della contribuzione, consultare le nostre guide correlate: -* [Rocky Linux Contribution Guide](https://docs.rockylinux.org/guides/contribute/) per i requisiti di sistema e software per iniziare. -* [Guida ai primi contributi di Rocky Linux](beginners.md) per un orientamento su GitHub, la nostra base di documentazione. -* [Formattazione di Rocky Docs](rockydocs_formatting.md) per la struttura Markdown. +- [Rocky Linux Contribution Guide](https://docs.rockylinux.org/guides/contribute/) per i requisiti di sistema e software per iniziare. +- [Guida ai primi contributi di Rocky Linux](beginners.md) per un orientamento su GitHub, la nostra base di documentazione. +- [Formattazione di Rocky Docs](rockydocs_formatting.md) per la struttura Markdown. ## Linee guida di stile @@ -38,31 +38,31 @@ Per una comprensione più completa della contribuzione, consultare le nostre gui Le **caratteristiche della scrittura tecnica** descritte nel Chicago Manual of Style sono le seguenti: -* Virgolette doppie ("stile Chicago") anziché singole (‘Oxford style’). -* I punti e le virgole vanno dentro le virgolette "così," anziché "così". -* Il trattino {shift}+{option}+{-} non ha spazi prima o dopo—come questo—ed è preferito per le frasi parentetiche. -* In un elenco di tre elementi, utilizzare una virgola prima di "e": "Piselli, senape, e carote" -* I titoli devono essere generalmente realizzati in stile titolo maiuscolo: La prima e l'ultima parola, così come tutti i nomi, i pronomi, i verbi e gli avverbi devono essere scritti in maiuscolo. Se il vostro documento funziona meglio con la capitalizzazione in stile frase, magari perché fate spesso riferimento ad acronimi, rendetela coerente all'interno dell'intero documento. -* I titoli non necessitano di un punto o di un punto e virgola alla fine, anche con una capitalizzazione di tipo frase, a meno che non terminino con un'abbreviazione. -* Elenchi puntati e numerati: Evitare la maiuscola iniziale o la punteggiatura finale, a meno che non si tratti di una frase completa. +- Virgolette doppie ("stile Chicago") anziché singole (‘Oxford style’). +- I punti e le virgole vanno dentro le virgolette "così," anziché "così". +- Il trattino {shift}+{option}+{-} non ha spazi prima o dopo—come questo—ed è preferito per le frasi parentetiche. +- In un elenco di tre elementi, utilizzare una virgola prima di "e": "Piselli, senape, e carote" +- I titoli devono essere generalmente realizzati in stile titolo maiuscolo: La prima e l'ultima parola, così come tutti i nomi, i pronomi, i verbi e gli avverbi devono essere scritti in maiuscolo. Se il vostro documento funziona meglio con la capitalizzazione in stile frase, magari perché fate spesso riferimento ad acronimi, rendetela coerente all'interno dell'intero documento. +- I titoli non necessitano di un punto o di un punto e virgola alla fine, anche con una capitalizzazione di tipo frase, a meno che non terminino con un'abbreviazione. +- Elenchi puntati e numerati: Evitare la maiuscola iniziale o la punteggiatura finale, a meno che non si tratti di una frase completa. ### Voce e Tono -* **Linguaggio semplice.** Questo può essere descritto come uno stile *meno colloquiale*. La maggior parte della nostra documentazione rientra in questo standard. - * Evitare metafore e modi di dire. - * Dite quello che volete dire con il minor numero di parole possibile. - * Identificare ed evitare termini inutilmente tecnici. Considerate che il vostro pubblico è costituito per lo più da persone che hanno una certa familiarità con l'argomento, ma che potrebbero non essere esperti della materia. - * Eccezioni al linguaggio semplice: - * Uno stile più colloquiale è appropriato per la documentazione rivolta ai neofiti o ai principianti o per la scrittura di contenuti come i post dei blog. - * Uno stile di scrittura più formale o conciso è appropriato per la documentazione rivolta agli utenti avanzati o per la documentazione sulle API (Application Programming Interface). -* **Linguaggio inclusivo.** - * L'uso della lingua si evolve nel tempo. Alcune parole si sono evolute assumendo una connotazione negativa, per cui la documentazione dovrebbe essere riscritta utilizzando parole nuove. - * *Master/slave* diventa *primario/secondario* o uno standard organizzativo concordato. - * La *blacklist/whitelist* diventa *blocklist/allowlist* o uno standard organizzativo concordato. - * Si possono pensare altri esempi pertinenti durante la creazione della documentazione. - * Quando si parla di una persona di genere *sconosciuto* o *non binario*, è ora considerato accettabile usare "loro" come pronome singolare. - * Quando si parla delle proprie capacità, inquadrare le risposte come *abilità* piuttosto che come *limitazioni.* Ad esempio, se vi chiedete se abbiamo documentazione sull'esecuzione di Steam su Rocky Linux, la risposta non è semplicemente "no" Piuttosto, "Sembra che sia un ottimo posto per creare qualcosa da aggiungere al nostro albero!" -* **Evitare le contrazioni.** Questo facilita gli sforzi di traduzione. L'eccezione è rappresentata dalla scrittura di testi dal tono più colloquiale, come i post di un blog o le istruzioni di benvenuto per i nuovi membri della comunità. +- **Linguaggio semplice.** Questo può essere descritto come uno stile *meno colloquiale*. La maggior parte della nostra documentazione rientra in questo standard. + - Evitare metafore e modi di dire. + - Dite quello che volete dire con il minor numero di parole possibile. + - Identificare ed evitare termini inutilmente tecnici. Considerate che il vostro pubblico è costituito per lo più da persone che hanno una certa familiarità con l'argomento, ma che potrebbero non essere esperti della materia. + - Eccezioni al linguaggio semplice: + - Uno stile più colloquiale è appropriato per la documentazione rivolta ai neofiti o ai principianti o per la scrittura di contenuti come i post dei blog. + - Uno stile di scrittura più formale o conciso è appropriato per la documentazione rivolta agli utenti avanzati o per la documentazione sulle API (Application Programming Interface). +- **Linguaggio inclusivo.** + - L'uso della lingua si evolve nel tempo. Alcune parole si sono evolute assumendo una connotazione negativa, per cui la documentazione dovrebbe essere riscritta utilizzando parole nuove. + - *Master/slave* diventa *primario/secondario* o uno standard organizzativo concordato. + - La *blacklist/whitelist* diventa *blocklist/allowlist* o uno standard organizzativo concordato. + - Si possono pensare altri esempi pertinenti durante la creazione della documentazione. + - Quando si parla di una persona di genere *sconosciuto* o *non binario*, è ora considerato accettabile usare "loro" come pronome singolare. + - Quando si parla delle proprie capacità, inquadrare le risposte come *abilità* piuttosto che come *limitazioni.* Ad esempio, se vi chiedete se abbiamo documentazione sull'esecuzione di Steam su Rocky Linux, la risposta non è semplicemente "no" Piuttosto, "Sembra che sia un ottimo posto per creare qualcosa da aggiungere al nostro albero!" +- **Evitare le contrazioni.** Questo facilita gli sforzi di traduzione. L'eccezione è rappresentata dalla scrittura di testi dal tono più colloquiale, come i post di un blog o le istruzioni di benvenuto per i nuovi membri della comunità. ## Formattazione @@ -74,15 +74,15 @@ Se possibile, utilizzare il nome del mese nel formato {day} {Month} {year}. Tutt Se si tratta di una procedura con una sola fase, utilizzare un punto piuttosto che un numero. Ad esempio: -* Implementate questa idea e andate avanti. +- Implementate questa idea e andate avanti. ### Linguaggio di interfaccia grafica -* Istruzioni testuali relative a un'interfaccia utente: Quando si descrive un comando da inserire in un'interfaccia utente, utilizzare la parola "enter" piuttosto che "put" o "type" Utilizzate un blocco di codice per scrivere il comando (cioè, impostatelo con i backtick): +- Istruzioni testuali relative a un'interfaccia utente: Quando si descrive un comando da inserire in un'interfaccia utente, utilizzare la parola "enter" piuttosto che "put" o "type" Utilizzate un blocco di codice per scrivere il comando (cioè, impostatelo con i backtick): *Esempio di testo Markdown* `Nella casella **messaggio di commit**, inserire update_thisdoc.` -* Nomi di elementi dell'interfaccia utente: Nomi **in grassetto** di elementi dell'interfaccia utente come pulsanti, voci di menu, nomi di finestre di dialogo e altro, anche se la parola non sarà cliccabile: +- Nomi di elementi dell'interfaccia utente: Nomi **in grassetto** di elementi dell'interfaccia utente come pulsanti, voci di menu, nomi di finestre di dialogo e altro, anche se la parola non sarà cliccabile: *Esempio di testo Markdown* `Nel menu **Format**, fare clic su **Line Spacing**.` @@ -90,11 +90,11 @@ Se si tratta di una procedura con una sola fase, utilizzare un punto piuttosto c ### Contenuto iniziale di ogni guida o pagina/capitolo di un libro -* **Abstract.** Una breve dichiarazione di ciò che ci si aspetta da questa pagina -* **Obiettivi.** Un elenco puntato di ciò che questa pagina trasmetterà al lettore -* **Competenze** richieste/apprese. -* **Livello di difficoltà.** 1 stella per facile, 2 per intermedio, ecc. -* **Tempo di lettura.** Dividete il numero di parole del documento per una velocità di lettura di 75 parole al minuto per determinare questo numero. +- **Abstract.** Una breve dichiarazione di ciò che ci si aspetta da questa pagina +- **Obiettivi.** Un elenco puntato di ciò che questa pagina trasmetterà al lettore +- **Competenze** richieste/apprese. +- **Livello di difficoltà.** 1 stella per facile, 2 per intermedio, ecc. +- **Tempo di lettura.** Dividete il numero di parole del documento per una velocità di lettura di 75 parole al minuto per determinare questo numero. ### Ammonimenti @@ -106,32 +106,32 @@ In Markdown, gli ammonimenti sono un modo per inserire le informazioni in un riq ### Immagini -* Fornite descrizioni testuali in alt-text o didascalie per ogni elemento non testuale come diagrammi, immagini o icone. -* Se possibile, evitate le schermate di testo. -* Rendere l'alt-text significativo, non solo descrittivo. Per le icone di azione, ad esempio, inserire una descrizione della funzione piuttosto che una descrizione dell'aspetto. +- Fornite descrizioni testuali in alt-text o didascalie per ogni elemento non testuale come diagrammi, immagini o icone. +- Se possibile, evitate le schermate di testo. +- Rendere l'alt-text significativo, non solo descrittivo. Per le icone di azione, ad esempio, inserire una descrizione della funzione piuttosto che una descrizione dell'aspetto. ### Link -* Rendete i link descrittivi, in modo che sia evidente la loro provenienza dal testo o dal contesto. Evitate i collegamenti ipertestuali con nomi come "clicca qui" -* Verificare che tutti i collegamenti funzionino come descritto. +- Rendete i link descrittivi, in modo che sia evidente la loro provenienza dal testo o dal contesto. Evitate i collegamenti ipertestuali con nomi come "clicca qui" +- Verificare che tutti i collegamenti funzionino come descritto. ### Tabelle -* Creare tabelle con un ordine logico da sinistra a destra, dall'alto in basso. -* Evitare le celle vuote nella parte superiore o sinistra della tabella. -* Evitare le celle unite che si estendono su più colonne. +- Creare tabelle con un ordine logico da sinistra a destra, dall'alto in basso. +- Evitare le celle vuote nella parte superiore o sinistra della tabella. +- Evitare le celle unite che si estendono su più colonne. ### Colori -* Alcuni elementi di Markdown, come gli ammonimenti, hanno un colore assegnato per facilitare la comprensione visiva. In genere hanno anche un nome assegnato; per esempio, l'ammonimento "pericolo" visualizza un riquadro rosso, ma ha anche il descrittore "danger" incorporato nella descrizione. Quando si crea un'ammonimento personalizzato, però, bisogna tenere presente che il colore non può essere l'unico mezzo per comunicare un comando o un livello di avvertimento. -* Qualsiasi comando che includa una direzione sensoriale, come *sopra* o *sotto*, *colore*, *dimensione*, *posizione visiva* nella pagina, ecc. dovrebbe includere anche una direzione comunicabile con la sola descrizione testuale. -* Quando si crea un elemento grafico, assicurarsi che il contrasto tra i colori di primo piano e di sfondo sia sufficiente per facilitare l'interpretazione da parte di uno screen reader. +- Alcuni elementi di Markdown, come gli ammonimenti, hanno un colore assegnato per facilitare la comprensione visiva. In genere hanno anche un nome assegnato; per esempio, l'ammonimento "pericolo" visualizza un riquadro rosso, ma ha anche il descrittore "danger" incorporato nella descrizione. Quando si crea un'ammonimento personalizzato, però, bisogna tenere presente che il colore non può essere l'unico mezzo per comunicare un comando o un livello di avvertimento. +- Qualsiasi comando che includa una direzione sensoriale, come *sopra* o *sotto*, *colore*, *dimensione*, *posizione visiva* nella pagina, ecc. dovrebbe includere anche una direzione comunicabile con la sola descrizione testuale. +- Quando si crea un elemento grafico, assicurarsi che il contrasto tra i colori di primo piano e di sfondo sia sufficiente per facilitare l'interpretazione da parte di uno screen reader. ### Intestazioni -* Utilizzate tutti i livelli di intestazione senza saltare alcun livello. -* Annidate tutto il materiale con titoli che ne favoriscano la leggibilità. -* Ricordate che in Markdown è possibile utilizzare un solo titolo di primo livello. +- Utilizzate tutti i livelli di intestazione senza saltare alcun livello. +- Annidate tutto il materiale con titoli che ne favoriscano la leggibilità. +- Ricordate che in Markdown è possibile utilizzare un solo titolo di primo livello. ## Sommario diff --git a/docs/guides/contribute/style_guide.uk.md b/docs/guides/contribute/style_guide.uk.md index 85d3ee6e74..978502ccdb 100644 --- a/docs/guides/contribute/style_guide.uk.md +++ b/docs/guides/contribute/style_guide.uk.md @@ -19,16 +19,16 @@ tags: У цьому посібнику описано стандарти стилю англійської мови, щоб **покращити читабельність, виділити виняткові випадки** та **поліпшити переклад** у документації Rocky Linux. Щодо запитань про стиль, які не розглядаються в цьому посібнику, зверніться до наступного: -* [Merriam Webster Dictionary](https://www.merriam-webster.com/) -* [Chicago Manual of Style (CMOS), 17th ed.](https://www.chicagomanualofstyle.org/home.html) +- [Merriam Webster Dictionary](https://www.merriam-webster.com/) +- [Chicago Manual of Style (CMOS), 17th ed.](https://www.chicagomanualofstyle.org/home.html) ### Зробити внесок Для повнішого розуміння того, як робити внески, зверніться до наших відповідних посібників: -* [Rocky Linux Contribution Guide](https://docs.rockylinux.org/guides/contribute/) містить вимоги до системи та програмного забезпечення для початку роботи. -* [Rocky Linux First Time Contributors Guide](beginners.md) для ознайомлення з GitHub, нашою базою документації. -* [Форматування Rocky Docs](../rockydocs_formatting/) для структури Markdown. +- [Rocky Linux Contribution Guide](https://docs.rockylinux.org/guides/contribute/) містить вимоги до системи та програмного забезпечення для початку роботи. +- [Rocky Linux First Time Contributors Guide](beginners.md) для ознайомлення з GitHub, нашою базою документації. +- [Форматування Rocky Docs](../rockydocs_formatting/) для структури Markdown. ## Рекомендації щодо стилю @@ -38,31 +38,31 @@ tags: **Ознаки технічного написання**, як зазначено в Чиказькому посібнику зі стилю, включають наступне: -* Подвійні лапки («стиль Чикаго»), а не одинарні лапки («стиль Оксфорд»). -* Крапки та коми беруться в лапки “ось так,” а не “ось так”. -* Тире {shift}+{option}+{-} не має пробілів ні перед, ні після, як це, і є кращим для фраз у дужках. -* Використовуйте послідовну кому перед «і» в списку з трьох елементів: «Горошок, гірчиця та морква». -* Заголовки, як правило, мають бути написані з великої літери: перше й останнє слова, а також усі іменники, займенники, дієслова та прислівники пишуться з великої літери. Якщо ваш документ краще працює з великими літерами в стилі речень, можливо, через те, що ви часто посилаєтеся на акроніми, зробіть це узгодженим у всьому документі. -* Заголовки не потребують крапки чи крапки з комою наприкінці, навіть якщо вони вживаються з великої літери, якщо вони не закінчуються абревіатурою. -* Маркіровані та пронумеровані списки: уникайте початку з великої літери або кінцевих знаків пунктуації, якщо елемент не є повним реченням. +- Подвійні лапки («стиль Чикаго»), а не одинарні лапки («стиль Оксфорд»). +- Крапки та коми беруться в лапки “ось так,” а не “ось так”. +- Тире {shift}+{option}+{-} не має пробілів ні перед, ні після, як це, і є кращим для фраз у дужках. +- Використовуйте послідовну кому перед «і» в списку з трьох елементів: «Горошок, гірчиця та морква». +- Заголовки, як правило, мають бути написані з великої літери: перше й останнє слова, а також усі іменники, займенники, дієслова та прислівники пишуться з великої літери. Якщо ваш документ краще працює з великими літерами в стилі речень, можливо, через те, що ви часто посилаєтеся на акроніми, зробіть це узгодженим у всьому документі. +- Заголовки не потребують крапки чи крапки з комою наприкінці, навіть якщо вони вживаються з великої літери, якщо вони не закінчуються абревіатурою. +- Маркіровані та пронумеровані списки: уникайте початку з великої літери або кінцевих знаків пунктуації, якщо елемент не є повним реченням. ### Голос і тон -* **Проста мова.** Це можна описати як *менш розмовний* стиль. Більшість нашої документації відповідає цьому стандарту. - * Уникайте метафор і ідіом. - * Скажіть те, що ви маєте на увазі, якомога меншою кількістю слів. - * Визначте та уникайте непотрібних технічних термінів. Подумайте, що ваша аудиторія – це переважно люди, які певною мірою знайомі з предметом, але можуть не бути експертами в цьому предметі. - * Винятки для простої мови: - * Більш розмовний стиль підходить для документації, адресованої новачкам або початківцям, або для написання вмісту, як-от дописів у блогах. - * Більш формальний або стислий стиль формулювання підходить для документації, адресованої досвідченим користувачам, або документації API (інтерфейс прикладного програмування). -* **Інклюзивна мова.** - * Використання мови розвивається з часом. Деякі слова еволюціонували, щоб нести негативні конотації, тому документацію слід переписати, щоб використовувати нові слова. - * *Master/slave* стає *primary/secondary* або узгодженим організаційним стандартом. - * *Blacklist/whitelist* стає *blocklist/allowlist* або узгодженим організаційним стандартом. - * Під час створення документації ви можете подумати про інші відповідні приклади. - * Говорячи про особу *невідомої* або *небінарної* статі, зараз вважається прийнятним використовувати "вони" як займенник однини. - * Говорячи про свої здібності, формулюйте відповіді як *здібності*, а не *обмеження.* Наприклад, якщо вам цікаво, чи ми маємо документацію про запуск Steam на Rocky Linux, відповідь не просто «ні». Скоріше, «Здається, це чудове місце для вас, щоб створити щось, щоб додати до нашого дерева!» -* **Уникайте скорочень.** Це допомагає з перекладом. Винятком є написання чогось у більш розмовному тоні, як-от публікації в блозі чи вітальні інструкції для нових учасників спільноти. +- **Проста мова.** Це можна описати як *менш розмовний* стиль. Більшість нашої документації відповідає цьому стандарту. + - Уникайте метафор і ідіом. + - Скажіть те, що ви маєте на увазі, якомога меншою кількістю слів. + - Визначте та уникайте непотрібних технічних термінів. Подумайте, що ваша аудиторія – це переважно люди, які певною мірою знайомі з предметом, але можуть не бути експертами в цьому предметі. + - Винятки для простої мови: + - Більш розмовний стиль підходить для документації, адресованої новачкам або початківцям, або для написання вмісту, як-от дописів у блогах. + - Більш формальний або стислий стиль формулювання підходить для документації, адресованої досвідченим користувачам, або документації API (інтерфейс прикладного програмування). +- **Інклюзивна мова.** + - Використання мови розвивається з часом. Деякі слова еволюціонували, щоб нести негативні конотації, тому документацію слід переписати, щоб використовувати нові слова. + - *Master/slave* стає *primary/secondary* або узгодженим організаційним стандартом. + - *Blacklist/whitelist* стає *blocklist/allowlist* або узгодженим організаційним стандартом. + - Під час створення документації ви можете подумати про інші відповідні приклади. + - Говорячи про особу *невідомої* або *небінарної* статі, зараз вважається прийнятним використовувати "вони" як займенник однини. + - Говорячи про свої здібності, формулюйте відповіді як *здібності*, а не *обмеження.* Наприклад, якщо вам цікаво, чи ми маємо документацію про запуск Steam на Rocky Linux, відповідь не просто «ні». Скоріше, «Здається, це чудове місце для вас, щоб створити щось, щоб додати до нашого дерева!» +- **Уникайте скорочень.** Це допомагає з перекладом. Винятком є написання чогось у більш розмовному тоні, як-от публікації в блозі чи вітальні інструкції для нових учасників спільноти. ## Форматування @@ -74,15 +74,15 @@ tags: Якщо у вас є процедура лише з одним кроком, використовуйте маркер, а не номер. Наприклад: -* Реалізуйте цю ідею і рухайтеся далі. +- Реалізуйте цю ідею і рухайтеся далі. ### Мова графічного інтерфейсу -* Текстові інструкції щодо інтерфейсу користувача: описуючи команду, яку потрібно ввести в інтерфейс користувача, використовуйте слово «enter», а не «put» або «type». Використовуйте блок коду, щоб написати команду (тобто встановити її зворотними галочками): +- Текстові інструкції щодо інтерфейсу користувача: описуючи команду, яку потрібно ввести в інтерфейс користувача, використовуйте слово «enter», а не «put» або «type». Використовуйте блок коду, щоб написати команду (тобто встановити її зворотними галочками): *Приклад тексту Markdown* `У полі **повідомлення про фіксацію** введіть update_thisdoc.` -* Назви елементів інтерфейсу користувача: **жирним шрифтом** назви елементів інтерфейсу, таких як кнопки, пункти меню, назви діалогових вікон тощо, навіть якщо це слово не можна натиснути: +- Назви елементів інтерфейсу користувача: **жирним шрифтом** назви елементів інтерфейсу, таких як кнопки, пункти меню, назви діалогових вікон тощо, навіть якщо це слово не можна натиснути: *Example Markdown text* `In the **Format** menu, click **Line Spacing**.` @@ -90,11 +90,11 @@ tags: ### Початковий вміст кожного посібника або сторінки/розділу книги -* **Анотація.** Коротка інформація про те, чого очікувати від цієї сторінки -* **Цілі.** Маркірований список того, що ця сторінка передасть читачеві -* **Навички** необхідні/вивчені. -* **Рівень складності.** 1 зірка для легкого, 2 для середнього тощо. -* **Час читання.** Щоб визначити це число, розділіть слова у вашому документі на швидкість читання 75 слів на хвилину. +- **Анотація.** Коротка інформація про те, чого очікувати від цієї сторінки +- **Цілі.** Маркірований список того, що ця сторінка передасть читачеві +- **Навички** необхідні/вивчені. +- **Рівень складності.** 1 зірка для легкого, 2 для середнього тощо. +- **Час читання.** Щоб визначити це число, розділіть слова у вашому документі на швидкість читання 75 слів на хвилину. ### Застереження @@ -106,32 +106,32 @@ tags: ### Зображення -* Надайте текстові описи в тексті заміщення або підписах для кожного нетекстового елемента, наприклад діаграм, зображень або значків. -* По можливості уникайте скріншотів із текстом. -* Зробіть альтернативний текст значущим, а не просто описовим. Для значків дій, наприклад, введіть опис функції, а не опис її вигляду. +- Надайте текстові описи в тексті заміщення або підписах для кожного нетекстового елемента, наприклад діаграм, зображень або значків. +- По можливості уникайте скріншотів із текстом. +- Зробіть альтернативний текст значущим, а не просто описовим. Для значків дій, наприклад, введіть опис функції, а не опис її вигляду. ### Посилання -* Зробіть посилання описовими, щоб було зрозуміло, куди вони ведуть із тексту чи контексту. Уникайте гіперпосилань із назвами на зразок «клацніть тут». -* Переконайтеся, що всі посилання працюють, як описано. +- Зробіть посилання описовими, щоб було зрозуміло, куди вони ведуть із тексту чи контексту. Уникайте гіперпосилань із назвами на зразок «клацніть тут». +- Переконайтеся, що всі посилання працюють, як описано. ### Таблиці -* Створюйте таблиці в логічному порядку зліва направо, зверху вниз. -* Уникайте порожніх клітинок у верхній або лівій частині таблиці. -* Уникайте об’єднаних клітинок, які охоплюють кілька стовпців. +- Створюйте таблиці в логічному порядку зліва направо, зверху вниз. +- Уникайте порожніх клітинок у верхній або лівій частині таблиці. +- Уникайте об’єднаних клітинок, які охоплюють кілька стовпців. ### Кольори -* Деяким елементам у Markdown, наприклад попередженням, призначено колір, щоб полегшити візуальне розуміння. Загалом, вони також мають присвоєну назву; наприклад, застереження «небезпека» відображає червону рамку, але також містить дескриптор «небезпека», вбудований в опис. Але, створюючи спеціальне попередження, майте на увазі, що колір не може бути єдиним засобом передачі команди або рівня попередження. -* Будь-яка команда, яка містить сенсорний напрямок, як-от *вище* або *нижче*, *колір*, *розмір*, *візуальне розташування* на сторінці тощо, також має включати напрямок, який можна передати лише текстовим описом. -* Створюючи графічний елемент, переконайтеся, що існує достатній контраст між кольорами переднього плану та фону, щоб програмі зчитування з екрана було легко інтерпретувати його. +- Деяким елементам у Markdown, наприклад попередженням, призначено колір, щоб полегшити візуальне розуміння. Загалом, вони також мають присвоєну назву; наприклад, застереження «небезпека» відображає червону рамку, але також містить дескриптор «небезпека», вбудований в опис. Але, створюючи спеціальне попередження, майте на увазі, що колір не може бути єдиним засобом передачі команди або рівня попередження. +- Будь-яка команда, яка містить сенсорний напрямок, як-от *вище* або *нижче*, *колір*, *розмір*, *візуальне розташування* на сторінці тощо, також має включати напрямок, який можна передати лише текстовим описом. +- Створюючи графічний елемент, переконайтеся, що існує достатній контраст між кольорами переднього плану та фону, щоб програмі зчитування з екрана було легко інтерпретувати його. ### Заголовки -* Використовуйте всі рівні заголовків, не пропускаючи рівні. -* Розташуйте весь матеріал під заголовками, щоб полегшити читання. -* Пам’ятайте, що в Markdown можна використовувати лише один заголовок першого рівня. +- Використовуйте всі рівні заголовків, не пропускаючи рівні. +- Розташуйте весь матеріал під заголовками, щоб полегшити читання. +- Пам’ятайте, що в Markdown можна використовувати лише один заголовок першого рівня. ## Підсумок diff --git a/docs/guides/contribute/style_guide.zh.md b/docs/guides/contribute/style_guide.zh.md index b7b402ae11..8b6751629d 100644 --- a/docs/guides/contribute/style_guide.zh.md +++ b/docs/guides/contribute/style_guide.zh.md @@ -19,16 +19,16 @@ tags: 本指南概述了英语样式的标准，以 **提高可读性、突出特例** 并加强整个 Rocky Linux 文档的 **翻译工作**。 对于本指南中未涉及的样式问题，请参考以下内容： -* [韦氏词典](https://www.merriam-webster.com/) -* [《芝加哥格式手册》（CMOS），第17版。](https://www.chicagomanualofstyle.org/home.html) +- [韦氏词典](https://www.merriam-webster.com/) +- [《芝加哥格式手册》（CMOS），第17版。](https://www.chicagomanualofstyle.org/home.html) ### 参与贡献 要更全面地了解贡献情况，请参阅我们的相关指南： -* [Rocky Linux 贡献指南](https://docs.rockylinux.org/guides/contribute/)，介绍入门所需的系统和软件要求。 -* [Rocky Linux 首次贡献指南](beginners.md)，介绍 GitHub 以及我们的文档主站。 -* [Rocky Docs 的 Markdown 结构格式](rockydocs_formatting.md)。 +- [Rocky Linux 贡献指南](https://docs.rockylinux.org/guides/contribute/)，介绍入门所需的系统和软件要求。 +- [Rocky Linux 首次贡献指南](beginners.md)，介绍 GitHub 以及我们的文档主站。 +- [Rocky Docs 的 Markdown 结构格式](rockydocs_formatting.md)。 ## 样式指南 @@ -38,31 +38,31 @@ tags: 《芝加哥格式手册》中概述的 **科技写作的特点** 包括： -* 双引号（"芝加哥风格"）而不是单引号（"牛津风格"）。 -* 句号和逗号要放在引号内，如 "like this,"，而不是 "like this"。 -* 破折号 {shift}+{option}+{-} 前后没有空格，如上所示，是括号短语的首选。 -* 在 "Peas, mustard, and carrots." 的列表中，在 "and" 前加一个逗号。 -* 标题通常应采用标题样式大写：第一个和最后一个单词以及所有名词、代词、动词和副词都要大写。 如果您的文档使用句子样式的大写形式效果更好，可能是因为您经常引用首字母缩写，请使其在整个文档中保持一致。 -* 标题末尾不需要句号或分号，即使使用句子样式的大写，除非以缩写结尾。 -* 有项目符号和编号的列表： 避免开头大写或结尾标点符号，除非该项目是一个完整的句子。 +- 双引号（"芝加哥风格"）而不是单引号（"牛津风格"）。 +- 句号和逗号要放在引号内，如 "like this,"，而不是 "like this"。 +- 破折号 {shift}+{option}+{-} 前后没有空格，如上所示，是括号短语的首选。 +- 在 "Peas, mustard, and carrots." 的列表中，在 "and" 前加一个逗号。 +- 标题通常应采用标题样式大写：第一个和最后一个单词以及所有名词、代词、动词和副词都要大写。 如果您的文档使用句子样式的大写形式效果更好，可能是因为您经常引用首字母缩写，请使其在整个文档中保持一致。 +- 标题末尾不需要句号或分号，即使使用句子样式的大写，除非以缩写结尾。 +- 有项目符号和编号的列表： 避免开头大写或结尾标点符号，除非该项目是一个完整的句子。 ### 语态与语气 -* **简明语言。**这可以被描述为一种 *较少交谈对话* 的样式。 我们的大部分文档都符合这一标准。 - * 避免使用比喻和成语。 - * 尽可能用最少的字表达你的意思。 - * 确定并避免不必要的专业术语。 考虑到你的受众主要是对主题有一定了解的人，但他们可能不是主题专家。 - * 简明语言的例外情况： - * 更具对话性的风格适用于面向新手或初学者的文档，或用于撰写博客文章等内容。 - * 更正式或更简洁的措辞风格适用于面向高级用户的文档或 API（Application Programming Interface) 文档。 -* **包容性语言。** - * 语言的使用会随着时间的推移而演变。 某些词语已经演变为具有负面含义，因此应重新编写文件，使用新词。 - * *Master/slave* 就变成了 *primary/secondary* 或约定俗成的组织标准。 - * *Blacklist/whitelist* 变成了 *blocklist/allowlist* 或约定俗成的组织标准。 - * 在创建文档时，您可能会想到其他相关的示例。 - * 当谈到 *unknown* 或 *non-binary* 性别的人时，现在认为可以将 "They" 用作单数代词。 - * 当谈到一个能力时，把答案框定为 *abilities* 而不是 *limitations*。例如，如果您想知道我们是否有关于在 Rocky Linux 上运行 Steam 的文档，答案不仅仅是 "no"。 而是说："听起来那是一个好地方，您可以创建一些东西来添加到我们的文档树中！" -* **避免缩约形式** 以助于翻译工作。 例外情况——在撰写博客文章或社区新成员欢迎说明等对话性较强的文章时。 +- **简明语言。**这可以被描述为一种 *较少交谈对话* 的样式。 我们的大部分文档都符合这一标准。 + - 避免使用比喻和成语。 + - 尽可能用最少的字表达你的意思。 + - 确定并避免不必要的专业术语。 考虑到你的受众主要是对主题有一定了解的人，但他们可能不是主题专家。 + - 简明语言的例外情况： + - 更具对话性的风格适用于面向新手或初学者的文档，或用于撰写博客文章等内容。 + - 更正式或更简洁的措辞风格适用于面向高级用户的文档或 API（Application Programming Interface) 文档。 +- **包容性语言。** + - 语言的使用会随着时间的推移而演变。 某些词语已经演变为具有负面含义，因此应重新编写文件，使用新词。 + - *Master/slave* 就变成了 *primary/secondary* 或约定俗成的组织标准。 + - *Blacklist/whitelist* 变成了 *blocklist/allowlist* 或约定俗成的组织标准。 + - 在创建文档时，您可能会想到其他相关的示例。 + - 当谈到 *unknown* 或 *non-binary* 性别的人时，现在认为可以将 "They" 用作单数代词。 + - 当谈到一个能力时，把答案框定为 *abilities* 而不是 *limitations*。例如，如果您想知道我们是否有关于在 Rocky Linux 上运行 Steam 的文档，答案不仅仅是 "no"。 而是说："听起来那是一个好地方，您可以创建一些东西来添加到我们的文档树中！" +- **避免缩约形式** 以助于翻译工作。 例外情况——在撰写博客文章或社区新成员欢迎说明等对话性较强的文章时。 ## 格式 @@ -74,15 +74,15 @@ tags: 如果您的过程只有一个步骤，请使用项目符号而不是数字。 例如： -* 落实这一想法，然后继续前进。 +- 落实这一想法，然后继续前进。 ### 图形界面语言 -* 关于 UI 的文本说明：当描述要输入到用户界面中的命令时，请使用单词 "enter"，而不是 "put" 或 "type"。 使用代码块写出命令（即用反引号将其设置）： +- 关于 UI 的文本说明：当描述要输入到用户界面中的命令时，请使用单词 "enter"，而不是 "put" 或 "type"。 使用代码块写出命令（即用反引号将其设置）： *示例 Markdown 文本* `在 **提交消息** 框中，输入 update_thisdoc。` -* UI 元素的名称：UI元素（如按钮、菜单项、对话框名称等）的 **粗体** 名称，即使单词不可单击： +- UI 元素的名称：UI元素（如按钮、菜单项、对话框名称等）的 **粗体** 名称，即使单词不可单击： *示例 Markdown 文本* `在 **Format** 菜单中，点击 **Line Spacing** 。` @@ -90,11 +90,11 @@ tags: ### 每本指南的开头内容，或一本书的页面/章节 -* **Abstract.** 简要说明本页的预期内容 -* **Objectives.** 本页将向读者传达的内容列表 -* **Skills** 需要或学习什么。 -* **Difficulty level.** 1星表示简单、2星表示中级等等。 -* **Reading time.** 将文件中的单词数除以每分钟 75 个单词的阅读速度，即可得出这一数字。 +- **Abstract.** 简要说明本页的预期内容 +- **Objectives.** 本页将向读者传达的内容列表 +- **Skills** 需要或学习什么。 +- **Difficulty level.** 1星表示简单、2星表示中级等等。 +- **Reading time.** 将文件中的单词数除以每分钟 75 个单词的阅读速度，即可得出这一数字。 ### Admonitions @@ -106,32 +106,32 @@ tags: ### 图片 -* 为每个非文本项目（如图表、图像或图标）提供替换文本或标题的文本描述。 -* 尽可能避免文本截屏。 -* 让替代文本有意义，而不仅仅是描述性的。 例如，对于操作图标，请输入功能描述而不是外观描述。 +- 为每个非文本项目（如图表、图像或图标）提供替换文本或标题的文本描述。 +- 尽可能避免文本截屏。 +- 让替代文本有意义，而不仅仅是描述性的。 例如，对于操作图标，请输入功能描述而不是外观描述。 ### 链接 -* 使链接具有描述性，这样就可以清楚地从文本或上下文中看到它们的指向。 避免使用名称类似 "click here" 的超链接。 -* 验证所有链接都能按描述正常工作。 +- 使链接具有描述性，这样就可以清楚地从文本或上下文中看到它们的指向。 避免使用名称类似 "click here" 的超链接。 +- 验证所有链接都能按描述正常工作。 ### 表格 -* 按照从左到右、从上到下的逻辑顺序创建表格。 -* 避免在表格顶部或左侧出现空白单元格。 -* 避免合并跨多列的单元格。 +- 按照从左到右、从上到下的逻辑顺序创建表格。 +- 避免在表格顶部或左侧出现空白单元格。 +- 避免合并跨多列的单元格。 ### 颜色 -* Markdown 中的一些元素，如 admonitions，它有指定的颜色来帮助视觉理解。 例如，"danger" admonition 会显示一个红框，但同时也有 "danger" 的描述。 但在创建自定义 admonition 时，请注意颜色不能作为传达命令或警告级别的唯一手段。 -* 任何包含感官指示（如 *above* 或 *below*、*color*、*size*、在页面上的 *visual location* 等）的指令，也应包含仅通过文字描述即可传达的指示。 -* 在创建图形元素时，确保前景色和背景色之间有足够的对比度，以便屏幕阅读器轻松解读。 +- Markdown 中的一些元素，如 admonitions，它有指定的颜色来帮助视觉理解。 例如，"danger" admonition 会显示一个红框，但同时也有 "danger" 的描述。 但在创建自定义 admonition 时，请注意颜色不能作为传达命令或警告级别的唯一手段。 +- 任何包含感官指示（如 *above* 或 *below*、*color*、*size*、在页面上的 *visual location* 等）的指令，也应包含仅通过文字描述即可传达的指示。 +- 在创建图形元素时，确保前景色和背景色之间有足够的对比度，以便屏幕阅读器轻松解读。 ### 标题 -* 使用所有级别的标题，不要跳过任何级别。 -* 将所有资料放在标题下，以帮助阅读。 -* 请记住，在 Markdown 中，只能使用一个一级标题。 +- 使用所有级别的标题，不要跳过任何级别。 +- 将所有资料放在标题下，以帮助阅读。 +- 请记住，在 Markdown 中，只能使用一个一级标题。 ## 总结