diff --git a/documentation/content/en/books/fdp-primer/writing-style/_index.adoc b/documentation/content/en/books/fdp-primer/writing-style/_index.adoc index a5f3379ffb..a3cd675081 100644 --- a/documentation/content/en/books/fdp-primer/writing-style/_index.adoc +++ b/documentation/content/en/books/fdp-primer/writing-style/_index.adoc @@ -1,370 +1,370 @@ --- title: Chapter 11. Writing Style prev: books/fdp-primer/manual-pages next: books/fdp-primer/editor-config description: Writing Style and some conventions used in the FreeBSD Documentation Project tags: ["writing", "style", "typos", "one sentence per line"] showBookMenu: true weight: 12 path: "/books/fdp-primer/" --- [[writing-style]] = Writing Style :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 11 :partnums: :source-highlighter: rouge :experimental: :images-path: books/fdp-primer/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[writing-style-tips]] == Tips Technical documentation can be improved by consistent use of several principles. Most of these can be classified into three goals: _be clear_, _be complete_, and _be concise_. These goals can conflict with each other. Good writing consists of a balance between them. [[writing-style-be-clear]] === Be Clear Clarity is extremely important. The reader may be a novice, or reading the document in a second language. Strive for simple, uncomplicated text that clearly explains the concepts. Avoid flowery or embellished speech, jokes, or colloquial expressions. Write as simply and clearly as possible. Simple text is easier to understand and translate. Keep explanations as short, simple, and clear as possible. Avoid empty phrases like "in order to", which usually just means "to". Avoid potentially patronizing words like "basically". Avoid Latin terms like "i.e.," or "cf.", which may be unknown outside of academic or scientific groups. Write in a formal style. Avoid addressing the reader as "you". For example, say "copy the file to [.filename]#/tmp#" rather than "you can copy the file to [.filename]#/tmp#". Give clear, correct, _tested_ examples. A trivial example is better than no example. A good example is better yet. Do not give bad examples, identifiable by apologies or sentences like "but really it should never be done that way". Bad examples are worse than no examples. Give good examples, because _even when warned not to use the example as shown_, the reader will usually just use the example as shown. Avoid _weasel words_ like "should", "might", "try", or "could". These words imply that the speaker is unsure of the facts, and create doubt in the reader. Similarly, give instructions as imperative commands: not "you should do this", but merely "do this". [[writing-style-be-complete]] === Be Complete Do not make assumptions about the reader's abilities or skill level. Tell them what they need to know. Give links to other documents to provide background information without having to recreate it. Put yourself in the reader's place, anticipate the questions they will ask, and answer them. [[writing-style-be-concise]] === Be Concise While features should be documented completely, sometimes there is so much information that the reader cannot easily find the specific detail needed. The balance between being complete and being concise is a challenge. One approach is to have an introduction, then a "quick start" section that describes the most common situation, followed by an in-depth reference section. [[writing-style-guidelines]] == Guidelines To promote consistency between the myriad authors of the FreeBSD documentation, some guidelines have been drawn up for authors to follow. Use American English Spelling:: There are several variants of English, with different spellings for the same word. Where spellings differ, use the American English variant. "color", not "colour", "rationalize", not "rationalise", and so on. + [NOTE] ==== The use of British English may be accepted in the case of a contributed article, however the spelling must be consistent within the whole document. The other documents such as books, web site, manual pages, etc. will have to use American English. ==== Do not use contractions:: Do not use contractions. Always spell the phrase out in full. "Don't use contractions" is wrong. + Avoiding contractions makes for a more formal tone, is more precise, and is slightly easier for translators. Use the serial comma:: In a list of items within a paragraph, separate each item from the others with a comma. Separate the last item from the others with a comma and the word "and". + For example: + This is a list of one, two and three items. + Is this a list of three items, "one", "two", and "three", or a list of two items, "one" and "two and three"? + It is better to be explicit and include a serial comma: + This is a list of one, two, and three items. Avoid redundant phrases:: Do not use redundant phrases. In particular, "the command", "the file", and "man command" are often redundant. + For example, commands: + Wrong: Use the `git` command to update sources. + Right: Use `git` to update sources. + Filenames: + Wrong: ... in the filename [.filename]#/etc/rc.local#... + Right: ... in [.filename]#/etc/rc.local#... + Manual page references (the second example uses `citerefentry` with the man:csh[1] entity):. + Wrong: See `man csh` for more information. + Right: See man:csh[1]. For more information about writing style, see http://www.bartleby.com/141/[Elements of Style], by William Strunk. [[writing-style-guide]] == Style Guide To keep the source for the documentation consistent when many different people are editing it, please follow these style conventions. [[one-sentence-per-line]] == One sentence per line Use Semantic Line Breaks in the documentation, a technique called "one sentence per line". The idea of this technique is to help the users to write and read documentation. To get more information about this technique read the link:https://sembr.org/[Semantic Line Breaks] page. This is an example which does not use "one sentence per line". .... All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. .... And this is an example which uses the technique. .... All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. .... [[writing-style-acronyms]] === Acronyms Acronyms should be defined the first time they appear in a document, as in: "Network Time Protocol (NTP)". After the acronym has been defined, use the acronym alone unless it makes more sense contextually to use the whole term. Acronyms are usually defined only once per chapter or per document. All acronyms should be enclosed using the ` character. [[writing-style-special-characters]] == Special Character List This list of special characters shows the correct syntax and the output when used in FreeBSD documentation. If a character is not on this list, ask about it on the {freebsd-doc}. [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Name | Syntax | Rendered | Copyright | +(C)+ | (C) | Registered | +(R)+ | (R) | Trademark | +(TM)+ | (TM) | Em dash | +--+ | -- | Ellipses | +...+ | ... | Single right arrow | +->+ | -> | Double right arrow | +=>+ | => | Single left arrow | +<-+ | <- | Double left arrow | +<=+ | <= |=== [[writing-style-linting-vale]] == Linting with Vale To maintain clarity and consistency across all documentation and website pages, link:https://vale.sh[Vale] styles have been introduced in the documentation tree. link:https://vale.sh[Vale] is a powerful linter for writing customized rules and can be used in multiple scenarios. At this moment link:https://vale.sh[Vale] can be used as a command line tool, for CI/CD pipeline and integrated into editor of choice. The following table describes the current rule names and respective severity. [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Name | Severity | BrandTerms | error | ConsciousLanguage | warning | Contractions | suggestions | EOLSpacing | warning | Hang | warning | Hyphens | warning | Repetition | warning | Spacing | error | Spelling | warning | Weasel | warning |=== [[writing-style-linting-vale-rules]] === Current Vale Rules . BrandTerms: Like The FreeBSD Project every major vendors and Companies have specific rules on writing their Brand Name. according to the Copyright rules of The FreeBSD Foundation *freebsd* should be written as *FreeBSD*. Similar to that care should be taken to be respective to other's brand value and write PostgreSQL, Node.js, Let's Encrypt etc. -Missing brand names should be added to the [.filename]#.vale/styles/FreeBSD/BrandTerms.yml#" in the `doc` repository. +Missing brand names should be added to the [.filename]#.vale/styles/FreeBSD/BrandTerms.yml# in the `doc` repository. . Contractions: Contracted words should not be used. This rule avoids all contractions and suggests full words. . Hang: `Hang` is often used to convey the meaning that the application has stopped responding. This rule proposes better wording. . Repetition: Same words are often typed twice when leaving the keyboard and rejoining the work again. This rule finds repeated words and warns the users. . Weasel: This rule handles avoiding weasel words. The uses of weasel words is controversial so at the moment the list of words are being evaluated and the severity level is marked as warning on. -In case a frequently used word is marked as weasel word it should be removed from [.filename]#.vale/styles/FreeBSD/Weasel.yml#" in the `doc` repository. +In case a frequently used word is marked as weasel word it should be removed from [.filename]#.vale/styles/FreeBSD/Weasel.yml# in the `doc` repository. . ConsciousLanguage: This rule proposes uses of conscious languages like avoiding the words white/black/master/slave. . EOLSpacing: In most of the documents EOL spacing is present which is not the desirable situation. . Hyphens: Often adverbs ending with 'ly' are being added with a hyphen which is wrong. . Spacing: Often double spaces are hard to catch on plain eye which is addressed here. . Spelling: At the moment there is a mix of en_US and en_UK spellings in the documentation and website. A custom dictionary from link:https://wordlist.aspell.net[Aspell] has been added which uses strictly en_US and do not accept the en_UK variant of any words. It has also an exception list to ignore the FreeBSD specific terms. -At the moment the list is a basic one with minimal words just as a proof of concept but if any word is found to be correct and not available in the dictionary the word should be added to the [.filename]#.vale/styles/FreeBSD/spelling-exceptions.txt#" in the `doc` repository. +At the moment the list is a basic one with minimal words just as a proof of concept but if any word is found to be correct and not available in the dictionary the word should be added to the [.filename]#.vale/styles/FreeBSD/spelling-exceptions.txt# in the `doc` repository. More rules will be introduced in the upcoming days when and where required. [[writing-style-using-vale]] === Using Vale link:https://vale.sh[Vale] can be used from command line and from within editor or IDE. package:textproc/vale[] can be installed as following: [source, shell] .... $ pkg install vale .... [[writing-style-using-vale-commandline]] ==== Using Vale in command line -Considering the fact that `doc` repository was cloned into [.filename]#~/doc#" the following commands are required to run: +Considering the fact that `doc` repository was cloned into [.filename]#~/doc# the following commands are required to run: [source, shell] .... % cd ~/doc % vale . .... [NOTE] ====== link:https://vale.sh[Vale] is a CPU and memory intensive program due to the nature of the application and can take a while to show any output on the screen. Better way to run the application is on specific folders or files rather than the entire `doc` repository as that is already done in the CI pipeline. ====== [[writing-style-using-vale-editors]] ==== Using Vale in editors link:https://vale.sh[Vale] works with major mainstream editors like package:editors/vim[], package:editors/emacs[], package:editors/vscode[]. At the moment the necessary configurations for package:editors/vim[] is described in crossref:editor-config[editor-config-vim, Vim]. Necessary configurations for package:editors/emacs[] is being worked on. diff --git a/documentation/content/pt-br/books/fdp-primer/writing-style/_index.adoc b/documentation/content/pt-br/books/fdp-primer/writing-style/_index.adoc index 04eee8d4a1..ab2c673dd0 100644 --- a/documentation/content/pt-br/books/fdp-primer/writing-style/_index.adoc +++ b/documentation/content/pt-br/books/fdp-primer/writing-style/_index.adoc @@ -1,315 +1,315 @@ --- description: 'Estilo de Escrita e algumas convenções usadas no Projeto de Documentação do FreeBSD' next: books/fdp-primer/editor-config path: /books/fdp-primer/ prev: books/fdp-primer/manual-pages showBookMenu: 'true' tags: ["writing", "style", "tipos", "one sentence per line"] title: 'Capítulo 11. Estilo de Escrita' weight: 12 --- [[writing-style]] = Estilo de escrita :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 11 :partnums: :source-highlighter: rouge :experimental: :images-path: books/fdp-primer/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[writing-style-tips]] == Dicas A documentação técnica pode ser melhorada pelo uso consistente de vários princípios. A maioria destes pode ser classificada em três objetivos: _ser claro_, _ser completo_ e _ser conciso_. Essas metas podem entrar em conflito umas com as outras. Uma boa escrita consiste em um equilíbrio entre eles. [[writing-style-be-clear]] === Seja claro A clareza é extremamente importante. O leitor pode ser um novato ou ler o documento em um segundo idioma. Esforce-se por um texto simples e descomplicado que explique claramente os conceitos. Evite discurso florido ou embelezado, piadas ou expressões coloquiais. Escreva da maneira mais simples e clara possível. Um texto simples é mais fácil de se entender e de se traduzir. Mantenha as explicações o mais curtas, simples e claras possíveis. Evite frases vazias como "a fim de" as quais normalmente significam apenas um "para". Evite palavras potencialmente paternalistas tais como "basicamente". Evite termos latinos como "i.e." ou "cf.", os quais podem ser desconhecidos fora de grupos acadêmicos ou científicos. Escreva em um estilo formal. Evite dirigir-se ao leitor como "você". Por exemplo, digamos "copie o arquivo para /tmp" em vez de "você pode copiar o arquivo para /tmp". Dê exemplos claros, corretos, e _testados_. Um exemplo trivial é melhor do que nenhum exemplo. Um bom exemplo é ainda melhor. Não dê exemplos ruins, identificáveis por desculpas ou frases como "mas realmente isso nunca deve ser feito dessa forma". Exemplos ruins são piores que nenhum exemplo. Dê bons exemplos, porque _mesmo quando avisado para não usar o exemplo como mostrado_ , o leitor normalmente só usa o exemplo como mostrado. Evite palavras vazias como "deveria", "poderia", "tentaria", ou "podia". Estas palavras implicam que o autor não tem certeza dos fatos e cria dúvidas no leitor. Da mesma forma, dê instruções como comandos imperativos: não utilize "você deve fazer isso", mas apenas "faça isso". [[writing-style-be-complete]] === Seja completo Não faça suposições sobre as habilidades do leitor. Diga-lhes o que precisam saber. Dê links para outros documentos para fornecer informações básicas sem precisar recriá-las. Coloque-se no lugar do leitor, antecipe as perguntas que eles farão e responda-os. [[writing-style-be-concise]] === Seja conciso Embora as funcionalidades devam ser documentadas completamente, às vezes existe tanta informação que o leitor não consegue encontrar facilmente os detalhes específicos de que necessita. O equilíbrio entre ser completo e ser conciso é um desafio. Uma abordagem é ter uma introdução e, em seguida, uma seção de "início rápido" que descreve a situação mais comum, seguida por uma seção de referência aprofundada. [[writing-style-guidelines]] == Diretrizes Para promover a consistência entre os inúmeros autores da documentação do FreeBSD, algumas diretrizes foram elaboradas para os autores seguirem. Use a Ortografia do Inglês Americano:: Existem várias variantes do Inglês, com grafias diferentes para a mesma palavra. Onde as grafias diferem, use a variante do Inglês Americano. "color", não "colour", "rationalize", não "rationalise", e assim por diante. + [NOTE] ==== O uso do Inglês Britânico pode ser aceito no caso de um artigo contribuído, no entanto, a ortografia deve ser consistente em todo o documento. Os outros documentos, como livros, site, páginas de manual, etc., terão que usar o Inglês Americano. ==== Não use contrações:: Não use contrações. Sempre soletre a frase na íntegra. "Do not" é a forma correta, "Don't" é a errada. + Evitar contrações contribui para um tom mais formal, é mais preciso e é um pouco mais fácil para os tradutores. Use a vírgula serial:: Em uma lista de itens dentro de um parágrafo, separe cada item dos outros com uma vírgula. Separe o último item dos outros com uma vírgula e a letra "e". + Por exemplo: + Esta é uma lista de um, dois e três itens. + Esta é uma lista de três itens, "um", "dois", e "três", ou uma lista de dois itens, "um" e "dois" e "três"? + É melhor ser explícito e incluir uma vírgula serial: + Esta é uma lista de um, dois, e três itens. Evite frases redundantes:: Não use frases redundantes. Em particular, "the command", "the file", e "man command" são frequentemente redundantes. + Por exemplo, comandos: + Errado: Use o comando `git` para atualizar o código fonte. + Correto: Use o `git` para atualizar o código fonte. + Nomes de arquivo: + Errado: ... no nome do arquivo [.filename]#/etc/rc.local#... + Correto: ... no [.filename]#/etc/rc.local#... + Referências de páginas de manual (o segundo exemplo usa `citerefentry` com a entidade man:csh[1]):. + Errado: veja `man csh` para mais informações. + Certo: Veja man:csh[1]. Para mais informações sobre o estilo de escrita, consulte http://www.bartleby.com/141/[Elements of Style], de William Strunk. [[writing-style-guide]] == Guia de estilo Para manter o código fonte da documentação consistente quando muitas pessoas diferentes a estiverem editando, siga estas convenções de estilo. [[one-sentence-per-line]] == Uma frase por linha Use quebras de linha semântica na documentação, uma técnica chamada "uma frase por linha". A ideia dessa técnica é ajudar os usuários a escrever e ler a documentação. Para obter mais informações sobre essa técnica, leia a página link:https://sembr.org/[Semantic Line Breaks]. Este é um exemplo que não usa "uma frase por linha". .... All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. .... E este é um exemplo que usa a técnica. .... All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. .... [[writing-style-acronyms]] === Siglas As siglas devem ser definidas na primeira vez que aparecerem em um documento, como em: "Network Time Protocol (NTP)". Depois que o acrônimo tiver sido definido, use apenas a sigla, a menos que faça mais sentido contextualmente usar todo o termo. Siglas geralmente são definidos apenas uma vez por capítulo ou por documento. Todas as siglas devem ser incluídas com o caractere `. [[writing-style-special-characters]] == Lista de Caracteres Especiais Esta lista de caracteres especiais mostra a sintaxe correta e a saída quando usada na documentação do FreeBSD. Se um caractere não está nesta lista, pergunte sobre ele na {freebsd-doc}. [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Nome | Sintaxe | Renderizado | Copyright | +(C)+ | (C) | Registrado | +(R)+ | (R) | Marca Comercial | +(TM)+ | (TM) | Travessão | +--+ | -- | Elipses | +...+ | ... | Seta simples para a direita | +->+ | -> | Seta dupla para a direita | +=>+ | => | Seta simples para a esquerda | +<-+ | <- | Seta dupla para a esquerda | +<=+ | <= |=== [[writing-style-linting-vale]] == Linting com Vale Para manter clareza e consistência em toda a documentação e páginas do site, estilos link:https://vale.sh[Vale] foram introduzidos na árvore de documentação. link:https://vale.sh[Vale] é um linter poderoso para escrever regras personalizadas e pode ser usado em vários cenários. Neste momento o link:https://vale.sh[Vale] pode ser usado como uma ferramenta de linha de comando, para pipeline de CI/CD e integrado ao editor de sua escolha. A tabela a seguir descreve os nomes das regras atuais e a respectiva severidade. [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Nome | Severidade | BrandTerms | error | ConsciousLanguage | warning | Contractions | suggestions | EOLSpacing | warning | Hang | warning | Hyphens | warning | Repetition | warning | Spacing | error | Spelling | warning | Weasel | warning |=== [[writing-style-linting-vale-rules]] === Current Vale Rules -. BrandTerms: Como o Projeto FreeBSD, todos os principais fornecedores e empresas têm regras específicas para escrever seu nome de marca. de acordo com as regras de Copyright da Fundação FreeBSD, *freebsd* deve ser escrito como *FreeBSD*. Da mesma forma, deve-se tomar cuidado para respeitar a escrita da marca de outros e escrever PostgreSQL, Node.js, Let's Encrypt, etc. Nomes de marcas ausentes devem ser adicionados ao [.filename]#.vale/styles/FreeBSD/BrandTerms.yml# " no repositório `doc`. +. BrandTerms: Como o Projeto FreeBSD, todos os principais fornecedores e empresas têm regras específicas para escrever seu nome de marca. de acordo com as regras de Copyright da Fundação FreeBSD, *freebsd* deve ser escrito como *FreeBSD*. Da mesma forma, deve-se tomar cuidado para respeitar a escrita da marca de outros e escrever PostgreSQL, Node.js, Let's Encrypt, etc. Nomes de marcas ausentes devem ser adicionados ao [.filename]#.vale/styles/FreeBSD/BrandTerms.yml# no repositório `doc`. . Contractions: Palavras contraídas não devem ser usadas. Esta regra evita todas as contrações e sugere palavras completas. . Hang: `Hang` é freqüentemente usado para transmitir o significado de que o aplicativo parou de responder. Esta norma propõe melhor redação. . Repetition: Muitas vezes, as mesmas palavras são digitadas duas vezes ao sair do teclado e voltar ao trabalho novamente. Esta regra encontra palavras repetidas e avisa os usuários. -. Weasel: Esta regra trata de evitar palavras de coloquiais. O uso de palavras coloquiais é controverso, então no momento a lista de palavras está sendo avaliada e o nível de gravidade está marcado como warning. No caso de uma palavra usada ser marcada com frequência como palavra coloquial, ela deve ser removida de [.filename]#.vale/styles/FreeBSD/Weasel.yml#" no repositório `doc`. +. Weasel: Esta regra trata de evitar palavras de coloquiais. O uso de palavras coloquiais é controverso, então no momento a lista de palavras está sendo avaliada e o nível de gravidade está marcado como warning. No caso de uma palavra usada ser marcada com frequência como palavra coloquial, ela deve ser removida de [.filename]#.vale/styles/FreeBSD/Weasel.yml# no repositório `doc`. . ConsciousLanguage: Esta regra propõe usos de linguagens conscientes como evitar as palavras white/black/master/slave - branco/negro/mestre/escravo. . EOLSpacing: Na maioria dos documentos, espaços no fim da linha (EOL) está presente, o que não é a situação desejável. . Hyphens: Muitas vezes advérbios que terminam com 'ly' são adicionados com um hífen, o que está errado. . Spacing: Freqüentemente, os espaços duplos são difíceis de se captar a olho nu, o que é abordado aqui. . Spelling: No momento, há uma mistura de grafias en_US e en_UK na documentação e no site. Um dicionário personalizado link:https://wordlist.aspell.net[Aspell] foi adicionado, que usa estritamente en_US e não aceita a variantes en_UK de nenhuma palavra. Ele também possui uma lista de exceções para ignorar os termos específicos do FreeBSD. No momento a lista é básica com o mínimo de palavras apenas como uma prova de conceito, mas se alguma palavra estiver correta e não estiver disponível no dicionário, a palavra deve ser adicionada ao [.filename]#.vale/styles/FreeBSD/spelling-exceptions.txt# no repositório `doc`. Mais regras serão introduzidas nos próximos dias, quando e onde for necessário. [[writing-style-using-vale]] === Utilizando o Vale O link:https://vale.sh[Vale] pode ser usado na linha de comando e no editor ou IDE. package:textproc/vale[] pode ser instalado da seguinte forma: [source, shell] .... $ pkg install vale .... [[writing-style-using-vale-commandline]] ==== Usando o Vale na linha de comando -Considerando o fato de que o repositório `doc` foi clonado em [.filename]#~/doc#" os seguintes comandos são necessários para executar: +Considerando o fato de que o repositório `doc` foi clonado em [.filename]#~/doc# os seguintes comandos são necessários para executar: [source, shell] .... % cd ~/doc % vale . .... [NOTE] ====== O link:https://vale.sh[Vale] é um programa intensivo de CPU e memória devido à natureza do aplicativo e pode demorar um pouco para mostrar qualquer saída na tela. A melhor maneira de executar o aplicativo é em diretórios ou arquivos específicos, em vez de todo o repositório `doc`, pois isso já é feito na pipeline de CI. ====== [[writing-style-using-vale-editors]] ==== Usando Vale em editores O link:https://vale.sh[Vale] funciona com os principais editores tradicionais como o package:editors/vim[], package:editors/emacs[], package:editors/vscode[]. No momento as configurações necessárias para package:editors/vim[] estão descritas em crossref:editor-config[editor-config-vim, Vim]. As configurações necessárias para package:editors/emacs[] estão sendo construídas.