[PATCH v3] docs: pt_BR: translate process/generated-content.rst

[Ygor Otavio <ygorotavio.sjc@gmail.com>]

Translate Documentation/process/generated-content.rst
into Brazilian Portuguese, maintaining consistency with
original formatting rules.
Add it to the pt_BR process documentation index.

Update the translation through commit d699a5da1039 ("docs: link AI coding assistants and tool-generated content pages")

Assisted-by: LLM
Signed-off-by: Ygor Otavio <ygorotavio.sjc@gmail.com>
---
Changes in v3:
- Add pt_BR subdirectory to the subject
- Add reference to the original commit
- Move changelog out of the commit message
- Wrap lines at 80 columns
- Fix title underline lengths
- Replace "submetedor" with "autor"
- Reword awkward passages as suggested
- Reorder generated-content before coding-assistants in index.rst

Changes in v2:
- Fixed errors in the commit

 .../pt_BR/process/generated-content.rst       | 117 ++++++++++++++++++
 .../translations/pt_BR/process/index.rst      |   1 +
 2 files changed, 118 insertions(+)
 create mode 100644 Documentation/translations/pt_BR/process/generated-content.rst

diff --git a/Documentation/translations/pt_BR/process/generated-content.rst b/Documentation/translations/pt_BR/process/generated-content.rst
new file mode 100644
index 000000000000..9a448f1dfff7
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/generated-content.rst
@@ -0,0 +1,117 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================================
+Diretrizes do Kernel para Conteúdo Gerado por Ferramentas
+=========================================================
+
+Propósito
+=========
+
+Os contribuidores do kernel vêm usando ferramentas para gerar contribuições há
+muito tempo. Essas ferramentas podem aumentar o volume de contribuições. Ao
+mesmo tempo, o tempo disponível de revisores e mantenedores é um recurso
+escasso. Entender quais partes de uma contribuição vêm de humanos e quais vêm de
+ferramentas ajuda a preservar esses recursos e manter o desenvolvimento do
+kernel saudável.
+
+O objetivo aqui é esclarecer as expectativas da comunidade em relação a
+ferramentas. Isso permite que todos se tornem mais produtivos, mantendo ao mesmo
+tempo um alto grau de confiança entre contribuidores e revisores.
+
+Fora do Escopo
+==============
+
+Estas diretrizes não se aplicam a ferramentas que fazem ajustes triviais em
+conteúdo preexistente. Também não dizem respeito a ferramentas que ajudam em
+tarefas menores. Alguns exemplos:
+
+ - Correções de ortografia e gramática, como reformular para o modo imperativo
+ - Auxílios de digitação como completar identificadores, boilerplate
+   ou completar padrões triviais
+ - Transformações puramente mecânicas, como renomear variáveis
+ - Reformatação, como executar o Lindent, ``clang-format`` ou ``rust-fmt``
+
+Mesmo quando o uso de ferramentas estiver fora do escopo, considere sempre se
+informar ao revisor a ferramenta utilizada ajudaria na revisão da sua
+contribuição.
+
+No Escopo
+=========
+
+Estas diretrizes se aplicam quando uma quantidade significativa de conteúdo em
+uma contribuição do kernel não foi escrita por uma pessoa presente na cadeia de
+Signed-off-by, mas sim criada por uma ferramenta.
+
+A detecção de um problema e o teste da correção para ele também fazem parte do
+processo de desenvolvimento; se uma ferramenta foi usada para encontrar um
+problema tratado por uma alteração, isso deve ser mencionado no changelog. Isso
+não apenas dá o devido crédito, como também ajuda outros desenvolvedores a
+descobrir essas ferramentas.
+
+Alguns exemplos:
+ - Qualquer correção sugerida por ferramenta, como ``checkpatch.pl --fix``
+ - Scripts do Coccinelle
+ - Um chatbot gerou uma nova função no seu patch para ordenar entradas de lista.
+ - Um arquivo .c do patch foi originalmente gerado por um assistente de
+    codificação, mas foi limpo manualmente.
+ - O changelog foi gerado entregando o patch a uma ferramenta de IA generativa e
+   pedindo que ela escrevesse o changelog.
+ - O changelog foi traduzido de outro idioma.
+
+Em caso de dúvida, escolha a transparência e presuma que estas diretrizes se
+aplicam à sua contribuição.
+
+Diretrizes
+==========
+
+Primeiro, leia o Developer's Certificate of Origin:
+Documentation/process/submitting-patches.rst. Suas regras são simples e estão em
+vigor há muito tempo. Elas já cobriram diversas contribuições geradas por
+ferramentas. Certifique-se de que você entende toda a sua submissão e está
+preparado para responder aos comentários de revisão.
+
+Segundo, ao fazer uma contribuição, seja transparente sobre a origem
+do conteúdo em cover letters e changelogs. Você pode ser mais
+transparente adicionando informações como:
+
+ - Quais ferramentas foram usadas?
+ - A entrada fornecida às ferramentas que você usou, como o script de origem do
+   Coccinelle.
+ - Se o código foi majoritariamente gerado a partir de um único prompt ou um
+   pequeno conjunto de prompts, inclua esses prompts. Para sessões mais longas,
+   inclua um resumo dos prompts e da natureza da assistência resultante.
+ - Quais partes do conteúdo foram afetadas por essa ferramenta?
+ - Como a submissão foi testada e quais ferramentas foram usadas para testar a
+   correção?
+
+Como em todas as contribuições, cada mantenedor tem a tem a discricionariedade
+de decidir como lidar ou tem autonomia. Por exemplo, eles podem:
+
+ - Tratá-la como qualquer outra contribuição.
+ - Rejeitá-la de imediato.
+ - Tratar a contribuição de forma especial, por exemplo, pedindo testes extras,
+   revisando com escrutínio adicional, ou revisando com prioridade menor do que
+   conteúdo gerado por humanos.
+ - Pedir algum outro passo especial, como solicitar que o contribuidor detalhe
+   como a ferramenta ou o modelo foi treinado.
+ - Pedir ao autor que explique a contribuição em mais detalhes, para que o
+    mantenedor possa se assegurar de que o autor entende completamente...
+    como o código funciona.
+ - Sugerir um prompt melhor em vez de sugerir alterações específicas de código.
+
+Se as ferramentas permitirem que você gere uma contribuição automaticamente,
+espere escrutínio adicional proporcional ao quanto dela foi gerado.
+
+Assim como ocorre com a saída de qualquer ferramenta, o resultado pode estar
+incorreto ou inadequado. Espera-se que você entenda e seja capaz de defender
+tudo o quesubmeter. Se você não for capaz de fazer isso, então não submeta as
+alterações resultantes.
+
+Se você o fizer mesmo assim, os mantenedores têm o direito de rejeitar sua série
+sem revisão detalhada.
+
+Referências
+===========
+
+Para diretrizes específicas sobre assistentes de codificação de IA, veja:
+* Documentation/process/coding-assistants.rst
\ No newline at end of file
diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documentation/translations/pt_BR/process/index.rst
index eda2a3fc5166..34eb92f5d458 100644
--- a/Documentation/translations/pt_BR/process/index.rst
+++ b/Documentation/translations/pt_BR/process/index.rst
@@ -58,6 +58,7 @@ Estas são as regras pelas quais tentamos viver na comunidade do kernel
    Interpretação do Código de Conduta do Kernel Linux <code-of-conduct-interpretation>
    Modelos de Maturidade para Contribuição no Kernel Linux <contribution-maturity-model.rst>
    Declaração sobre Drivers do Kernel <kernel-driver-statement>
+   Diretrizes do Kernel para Conteúdo Gerado por Ferramentas <generated-content>   
    Estilo de gerenciamento do kernel Linux <management-style>
    Conclave (Continuidade do projeto) <conclave>
 
-- 
2.56.0