[PATCH 00/11] docs/translations/pt_BR: process: sync with English and fix errors

[PATCH 00/11] docs/translations/pt_BR: process: sync with English and fix errors

[Daniel Pereira]

This series reviews part of the Brazilian Portuguese translation of
Documentation/process against the English originals.

Patches 2-6 sync coding-assistants.rst, security-bugs.rst,
maintainer-netdev.rst, maintainer-soc.rst and changes.rst with changes
made to the originals. The other patches fix translation errors against
the English text, markup that renders differently from the original,
and cross-references that pointed to the English documents even though
the targets are translated, adding the pt_BR labels needed for that.

The changes are limited to updates and fixes; nothing is rewritten.
"make htmldocs" builds without new warnings.

Daniel Pereira (11):
  docs/translations/pt_BR: process: fix 1.Intro.rst and add labels
  docs/translations/pt_BR: process: coding-assistants.rst: add bug
    procedure
  docs/translations/pt_BR: process: security-bugs.rst: sync with English
  docs/translations/pt_BR: process: maintainer-netdev.rst: sync with
    English
  docs/translations/pt_BR: process: maintainer-soc.rst: sync with
    English
  docs/translations/pt_BR: process: changes.rst: sync with English
  docs/translations/pt_BR: process: license-rules.rst: fix lists and
    table
  docs/translations/pt_BR: process: 2.Process.rst: fix translation
    errors
  docs/translations/pt_BR: process: fix cross-references and list markup
  docs/translations/pt_BR: process: restore links, emphasis and headings
  docs/translations/pt_BR: process: fix kernel-docs and enforcement
    statement

 .../translations/pt_BR/process/1.Intro.rst    | 382 +++++++++---------
 .../translations/pt_BR/process/2.Process.rst  |  48 ++-
 .../pt_BR/process/3.Early-stage.rst           |   2 +
 .../translations/pt_BR/process/4.Coding.rst   |   8 +-
 .../translations/pt_BR/process/5.Posting.rst  |  24 +-
 .../pt_BR/process/6.Followthrough.rst         |   2 +
 .../pt_BR/process/7.AdvancedTopics.rst        |   4 +
 .../pt_BR/process/8.Conclusion.rst            |   9 +-
 .../pt_BR/process/backporting.rst             |   6 +-
 .../translations/pt_BR/process/changes.rst    |  61 +--
 .../pt_BR/process/coding-assistants.rst       |  45 ++-
 .../pt_BR/process/coding-style.rst            |  14 +-
 .../pt_BR/process/email-clients.rst           |  12 +-
 .../process/embargoed-hardware-issues.rst     |   2 +-
 .../translations/pt_BR/process/howto.rst      |   4 +-
 .../pt_BR/process/kernel-docs.rst             |  16 +-
 .../process/kernel-enforcement-statement.rst  |   1 +
 .../pt_BR/process/license-rules.rst           |  18 +-
 .../pt_BR/process/maintainer-kvm-x86.rst      |   2 +-
 .../pt_BR/process/maintainer-netdev.rst       |  76 ++--
 .../pt_BR/process/maintainer-soc.rst          |  20 +-
 .../pt_BR/process/management-style.rst        |   6 +-
 .../pt_BR/process/security-bugs.rst           |  53 ++-
 .../pt_BR/process/stable-api-nonsense.rst     |   2 +
 .../pt_BR/process/submit-checklist.rst        |   4 +-
 25 files changed, 482 insertions(+), 339 deletions(-)


base-commit: f857ff5bf007f3394b704e200096571cbffdcc3a
-- 
2.47.3

[PATCH 01/11] docs/translations/pt_BR: process: fix 1.Intro.rst and add labels

[Daniel Pereira]

Review 1.Intro.rst against the English original and fix the
translation:

- Fix mistranslations: "driver disks", "proprietary kernel modules",
  "sent to the right place", "reviewing patches posted by others"
  (it said the patches were reviewed by others), "language" in the
  licensing section (legal wording, not a programming language),
  "foreseeable future", "developers and their employers" and the
  grouping of "the patch development, review, and merging cycle".
- Restore words that were dropped, such as "and other software
  vendors", "nonstandard", "binary-only", "from the community",
  "outside developers", "legal status", "however" and "help ensure".
- Use the same terms throughout the document and as the rest of the
  pt_BR translation: "contribuidores", "comunidade de desenvolvimento",
  "listas de discussão", "kernel Linux" and "mainline".
- Fix grammar and style issues (agreement, prepositions, gerunds and
  anglicisms such as "em existência").
- Rename "Sumário" to "Resumo executivo" ("Executive summary").

The :ref: links in 1.Intro.rst pointed to the labels of the English
documents, so they sent the reader out of the translation. Add
pt_BR_development_* labels to 1.Intro.rst through 8.Conclusion.rst,
mirroring the labels of the English documents with the pt_BR_ prefix
used by the other pt_BR documents, and use them in the references.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../translations/pt_BR/process/1.Intro.rst    | 382 +++++++++---------
 .../translations/pt_BR/process/2.Process.rst  |   2 +
 .../pt_BR/process/3.Early-stage.rst           |   2 +
 .../translations/pt_BR/process/4.Coding.rst   |   2 +
 .../translations/pt_BR/process/5.Posting.rst  |   2 +
 .../pt_BR/process/6.Followthrough.rst         |   2 +
 .../pt_BR/process/7.AdvancedTopics.rst        |   2 +
 .../pt_BR/process/8.Conclusion.rst            |   2 +
 8 files changed, 210 insertions(+), 186 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/1.Intro.rst b/Documentation/translations/pt_BR/process/1.Intro.rst
index 2995fa49e..3592e573b 100644
--- a/Documentation/translations/pt_BR/process/1.Intro.rst
+++ b/Documentation/translations/pt_BR/process/1.Intro.rst
@@ -1,264 +1,274 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_process_intro:
+
 Introdução
 ==========
 
-Sumário
--------
-
-O restante desta seção cobre o processo de desenvolvimento do kernel e os
-tipos de frustração que os desenvolvedores e empresas podem encontrar pelo
-caminho. Existem diversas razões que justificam a recomendação para que seja
-feito o merge do código do kernel ao kernel principal ("mainline"), como
-disponibilidade automática aos usuários, suporte da comunidade em diversas
-formas, e a oportunidade de influenciar a direção do desenvolvimento do
-kernel. Contribuições ao kernel Linux obrigatoriamente devem estar disponíveis
-sob uma licença compatível com a GPL.
-
-:ref:`development_process` apresenta o processo de desenvolvimento, o ciclo de
-lançamento, e a mecânica da janela de merge. As várias fases no desenvolvimento
-de patch, revisão, e ciclo de merge são explicadas. Algumas ferramentas e
-listas de e-mail são discutidas. Desenvolvedores que queiram começar a
-desenvolver o kernel são encorajados a buscar e corrigir bugs como exercício
-inicial.
-
-:ref:`development_early_stage` cobre os primeiros passos do processo de
-desenvolvimento, com ênfase no envolvimento da comunidade de desenvolvedores o
+Resumo executivo
+----------------
+
+O restante desta seção cobre o escopo do processo de desenvolvimento do kernel
+e os tipos de frustração que os desenvolvedores e seus empregadores podem
+encontrar pelo caminho. Há inúmeras razões pelas quais o código do kernel deve
+ser integrado ao kernel oficial ("mainline"), entre elas a disponibilidade
+automática para os usuários, o suporte da comunidade em diversas formas e a
+capacidade de influenciar a direção do desenvolvimento do kernel. O código
+contribuído ao kernel Linux deve ser disponibilizado sob uma licença compatível
+com a GPL.
+
+:ref:`pt_BR_development_process` apresenta o processo de desenvolvimento, o
+ciclo de lançamento do kernel e a mecânica da janela de merge. As várias fases
+do ciclo de desenvolvimento, revisão e merge de patches são explicadas. Também
+são abordadas algumas ferramentas e listas de discussão. Desenvolvedores que
+queiram começar no desenvolvimento do kernel são encorajados a localizar e
+corrigir bugs como exercício inicial.
+
+:ref:`pt_BR_development_early_stage` cobre o planejamento de projetos em
+estágio inicial, com ênfase no envolvimento da comunidade de desenvolvimento o
 mais cedo possível.
 
-:ref:`development_coding` é sobre o processo de codificação; muitas armadilhas
-já encontradas por outros desenvolvedores são discutidas. Alguns requisitos
-para patches são explicados, e é feita uma introdução para algumas ferramentas
-que podem ajudar a garantir que os patches de kernel estão corretos.
+:ref:`pt_BR_development_coding` é sobre o processo de codificação; várias
+armadilhas já encontradas por outros desenvolvedores são discutidas. Alguns
+requisitos para patches são explicados, e é feita uma introdução a algumas das
+ferramentas que podem ajudar a garantir que os patches de kernel estejam
+corretos.
 
-:ref:`development_posting` fala sobre o processo de envio de patches para
-revisão. Para serem levados em consideração pela comunidade desenvolvedora, os
-patches devem estar devidamente formatados e descritos, assim como devem estar
-no lugar correto. Seguir os conselhos dessa seção pode ajudar na recepção
-positiva do seu trabalho.
+:ref:`pt_BR_development_posting` fala sobre o processo de envio de patches para
+revisão. Para serem levados a sério pela comunidade de desenvolvimento, os
+patches devem estar devidamente formatados e descritos, e devem ser enviados ao
+lugar correto. Seguir os conselhos dessa seção deve ajudar a garantir a melhor
+recepção possível para o seu trabalho.
 
-:ref:`development_followthrough` cobre o que acontece após o envio dos patches;
-o trabalho ainda está longe de estar concluído. Trabalhar com os revisores é
-parte crucial do processo de desenvolvimento; essa seção oferece dicas de como
-evitar problemas nesse estágio importante. Desenvolvedores são alertados a não
-presumir que o trabalho acabou após o merge do patch no "mainline".
+:ref:`pt_BR_development_followthrough` cobre o que acontece após o envio dos
+patches; nesse ponto, o trabalho ainda está longe de estar concluído. Trabalhar
+com os revisores é parte crucial do processo de desenvolvimento; essa seção
+oferece diversas dicas sobre como evitar problemas nesse estágio importante.
+Desenvolvedores são alertados para não presumir que o trabalho acabou após o
+merge do patch no "mainline".
 
-:ref:`development_advancedtopics` introduz dois tópicos mais "avançados":
-gerenciamento de patches com git e revisão de patches por outros.
+:ref:`pt_BR_development_advancedtopics` introduz dois tópicos "avançados":
+gerenciamento de patches com Git e revisão de patches enviados por outros.
 
-:ref:`development_conclusion` conclui o documento com indicações de fontes com
-mais informações sobre o desenvolvimento do kernel.
+:ref:`pt_BR_development_conclusion` conclui o documento com indicações de
+fontes com mais informações sobre o desenvolvimento do kernel.
 
 Sobre este documento
 --------------------
 
 O kernel Linux, com mais de 8 milhões de linhas de código e bem mais de 1000
-contribuintes a cada lançamento ("release"), é um dos maiores e mais ativos
-projetos de software livre em existência. Desde seu modesto início em 1991,
-este kernel evoluiu para se tornar um dos melhores componentes de sistemas
-operacionais, rodando em pequenos players de música digital, PCs de mesa, os
-maiores supercomputadores em existência, e todos os outros tipos de sistema
-entre eles. É robusto, eficiente, e uma solução escalável para quase toda
-situação.
-
-O crescimento do Linux trouxe o aumento no número de desenvolvedores (e
-empresas) desejando participar no seu desenvolvimento. Fabricantes de hardware
-querem garantir que o Linux suporte bem os seus produtos, tornando-os atrativos
-para usuários Linux. Fabricantes de sistemas embarcados, que usam o Linux como
-componente em um produto integrado, querem que o Linux seja tão capaz e
-adequado quanto possível para a tarefa em questão. Distribuidores de software
-que baseiam seus produtos em Linux têm claro interesse nas capacidades,
-performance, e confiabilidade do kernel Linux. É também comum que usuários
-finais queiram alterar o Linux para atender melhor suas necessidades.
-
-Uma das características mais atrativas do Linux é sua facilidade de acesso a
-esses desenvolvedores; qualquer um com as habilidades necessárias pode melhorar
-o Linux e influenciar a direção do seu desenvolvimento. Produtos proprietários
+contribuidores a cada lançamento ("release"), é um dos maiores e mais ativos
+projetos de software livre existentes. Desde seu modesto início em 1991, este
+kernel evoluiu para se tornar um componente de sistema operacional de primeira
+linha, que roda em players de música digital de bolso, em PCs de mesa, nos
+maiores supercomputadores existentes e em todos os tipos de sistema
+intermediários. É uma solução robusta, eficiente e escalável para quase
+qualquer situação.
+
+O crescimento do Linux trouxe um aumento no número de desenvolvedores (e
+empresas) que desejam participar do seu desenvolvimento. Fabricantes de
+hardware querem garantir que o Linux suporte bem os seus produtos, tornando-os
+atrativos para usuários Linux. Fabricantes de sistemas embarcados, que usam o
+Linux como componente em um produto integrado, querem que o Linux seja tão
+capaz e adequado quanto possível para a tarefa em questão. Distribuidores e
+outros fornecedores de software que baseiam seus produtos em Linux têm claro
+interesse nas capacidades, no desempenho e na confiabilidade do kernel Linux.
+Usuários finais também costumam querer alterar o Linux para que ele atenda
+melhor às suas necessidades.
+
+Uma das características mais atrativas do Linux é ser acessível a esses
+desenvolvedores; qualquer um com as habilidades necessárias pode melhorar o
+Linux e influenciar a direção do seu desenvolvimento. Produtos proprietários
 não conseguem oferecer esse tipo de abertura, que é característico do processo
-de software livre. O kernel é ainda mais acessível que a maioria dos outros
-projetos de software livre. Um ciclo típico de três meses de desenvolvimento
-do kernel pode envolver mais de 1000 desenvolvedores trabalhando para mais de
-100 empresas (ou absolutamente nenhuma empresa).
-
-Trabalhar com a comunidade de desenvolvimento do kernel não é uma tarefa árdua.
-Contudo, muitos colaboradores potenciais passaram por dificuldades ao tentar
-trabalhar no kernel. A comunidade evoluiu suas próprias formas de funcionamento
-que permitem operar de forma fluida (e produzir um produto de alta qualidade)
-em um ambiente em que milhares de linhas de código são alteradas todos os dias.
-Não é surpresa que o processo de desenvolvimento do kernel Linux seja muito
-diferente dos modelos de desenvolvimento proprietários.
+de software livre. Na verdade, o kernel é ainda mais aberto que a maioria dos
+outros projetos de software livre. Um ciclo típico de três meses de
+desenvolvimento do kernel pode envolver mais de 1000 desenvolvedores
+trabalhando para mais de 100 empresas diferentes (ou para nenhuma empresa).
+
+Trabalhar com a comunidade de desenvolvimento do kernel não é especialmente
+difícil. Ainda assim, muitos contribuidores em potencial passaram por
+dificuldades ao tentar trabalhar no kernel. A comunidade do kernel desenvolveu
+formas próprias e distintas de funcionamento, que lhe permitem operar de forma
+fluida (e produzir um produto de alta qualidade) em um ambiente em que milhares
+de linhas de código são alteradas todos os dias. Portanto, não é surpresa que o
+processo de desenvolvimento do kernel Linux seja muito diferente dos métodos de
+desenvolvimento proprietários.
 
 O processo de desenvolvimento do kernel pode parecer estranho e intimidador
 para novos desenvolvedores, mas existem bons motivos e uma sólida experiência
-por trás disso. Um desenvolvedor que não entenda os caminhos próprios da
-comunidade kernel (ou pior, que tente menosprezá-los ou contorná-los) terá uma
-experiência frustrante pela frente. A comunidade de desenvolvimento ajuda
-aqueles que tentam aprender, mas gasta pouco tempo com aqueles que não escutam
-ou não ligam para o processo de desenvolvimento.
+por trás dele. Um desenvolvedor que não entenda os costumes da comunidade do
+kernel (ou, pior, que tente desrespeitá-los ou contorná-los) terá uma
+experiência frustrante pela frente. A comunidade de desenvolvimento, embora
+ajude aqueles que tentam aprender, tem pouco tempo para aqueles que não escutam
+ou não se importam com o processo de desenvolvimento.
 
-Espera-se que aqueles que leiam este documento sejam capazes de evitar essa
+Espera-se que aqueles que lerem este documento sejam capazes de evitar essa
 experiência frustrante. Há muito material aqui, mas o esforço envolvido na sua
-leitura valerá a pena. A comunidade de desenvolvimento sempre necessita de
-desenvolvedores que ajudem a melhorar o kernel; o texto a seguir deve ajudar
-você - ou aqueles trabalhando para você - a se juntar à nossa comunidade.
+leitura será recompensado em pouco tempo. A comunidade de desenvolvimento
+sempre necessita de desenvolvedores que ajudem a melhorar o kernel; o texto a
+seguir deve ajudar você - ou aqueles que trabalham para você - a se juntar à
+nossa comunidade.
 
 Créditos
 --------
 
-Esse documento foi escrito por Jonathan Corbet, corbet@lwn.net. Aprimorado
-pelos comentários de Johannes Berg, James Berry, Alex Chiang, Roland Dreier,
-Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda
-McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, e Jochen Voß.
+Este documento foi escrito por Jonathan Corbet, corbet@lwn.net. Ele foi
+aprimorado com comentários de Johannes Berg, James Berry, Alex Chiang, Roland
+Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
+Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata e Jochen Voß.
 
-Esse trabalho contou com o apoio da Linux Foundation; agradecimentos especiais
-para Amanda McPherson, que viu o valor desse esforço e fez tudo acontecer.
+Este trabalho contou com o apoio da Linux Foundation; agradecimentos especiais
+a Amanda McPherson, que viu o valor desse esforço e fez tudo acontecer.
 
 A importância de levar o código até o "mainline"
 -------------------------------------------------
 
-Algumas empresas e desenvolvedores ocasionalmente se perguntam por que devem
-se importar em aprender como trabalhar com a comunidade do kernel e ter seu
-código no "mainline" (o kernel mantido por Linus Torvalds e usado como base
-para os distribuidores Linux). No curto prazo, contribuir com o código pode
-parecer um gasto evitável; parece mais fácil apenas manter o seu código à
-parte e oferecer suporte direto aos usuários. A verdade é que manter código
-fora da árvore principal ("out-of-tree") é uma falsa economia.
+Algumas empresas e desenvolvedores ocasionalmente se perguntam por que deveriam
+se preocupar em aprender a trabalhar com a comunidade do kernel e em levar seu
+código ao "mainline" (o kernel mantido por Linus Torvalds e usado como base
+pelos distribuidores Linux). No curto prazo, contribuir com código pode parecer
+um gasto evitável; parece mais fácil apenas manter o código à parte e oferecer
+suporte direto aos usuários. A verdade é que manter código fora da árvore
+principal ("out-of-tree") é uma falsa economia.
 
 Para ilustrar os custos do código "out-of-tree", aqui estão alguns aspectos
 relevantes do processo de desenvolvimento do kernel; a maioria será discutida
 com mais detalhes adiante neste documento. Considere:
 
 - Código integrado via merge ao "mainline" fica disponível para todos os
-  usuários Linux. Estará automaticamente presente em todas as distribuições
-  que o habilitarem. Não há necessidade de discos de armazenamento, downloads,
-  ou as complicações de dar suporte a múltiplas versões de variadas
-  distribuições; tudo simplesmente funciona, para o desenvolvedor e para o
-  usuário. Incorporação ao "mainline" resolve um grande número de problemas
-  de distribuição e suporte.
-
-- Enquanto desenvolvedores do kernel se esforçam para manter uma interface
-  estável para o espaço do usuário, a API interna está em constante mudança.
-  A ausência de uma interface interna estável é uma escolha deliberada de
-  design; permite que sejam feitas melhorias fundamentais a qualquer tempo e
-  resulta em código de qualidade superior. Uma consequência dessa política é
-  que código "out-of-tree" precisa ser constantemente atualizado para que
-  continue funcionando com novos kernels. Manter código "out-of-tree" requer
-  significativo trabalho apenas para mantê-lo funcionando.
-
-  Por sua vez, código que está no "mainline" não precisa dessa manutenção,
-  resultado de uma regra simples que exige que qualquer desenvolvedor que
-  altere uma API, também conserte qualquer código que deixe de funcionar como
-  resultado da alteração. Código que teve o merge realizado no "mainline" tem
-  custo significativamente menor de manutenção.
+  usuários Linux. Estará automaticamente presente em todas as distribuições que
+  o habilitarem. Não há necessidade de discos de drivers, downloads ou das
+  complicações de dar suporte a múltiplas versões de múltiplas distribuições;
+  tudo simplesmente funciona, para o desenvolvedor e para o usuário. A
+  incorporação ao "mainline" resolve um grande número de problemas de
+  distribuição e suporte.
+
+- Embora os desenvolvedores do kernel se esforcem para manter uma interface
+  estável para o espaço do usuário, a API interna do kernel está em constante
+  mudança. A ausência de uma interface interna estável é uma decisão deliberada
+  de design; ela permite que melhorias fundamentais sejam feitas a qualquer
+  momento e resulta em código de qualidade superior. Mas uma consequência dessa
+  política é que qualquer código "out-of-tree" exige manutenção constante para
+  funcionar com novos kernels. Manter código "out-of-tree" requer um trabalho
+  significativo apenas para que ele continue funcionando.
+
+  Por sua vez, o código que está no "mainline" não precisa desse trabalho,
+  graças a uma regra simples que exige que qualquer desenvolvedor que altere
+  uma API também conserte qualquer código que deixe de funcionar como resultado
+  dessa alteração. Portanto, o código que passou pelo merge no "mainline" tem
+  custos de manutenção significativamente menores.
 
 - Além disso, código que está no kernel será muitas vezes melhorado por outros
   desenvolvedores. Resultados surpreendentes podem surgir ao permitir que sua
   comunidade de usuários e clientes melhore seu produto.
 
-- Código do kernel está sujeito a revisão, tanto antes como depois do merge ao
-  "mainline". Independentemente das habilidades do desenvolvedor original, o
-  processo de revisão invariavelmente encontra maneiras de evoluí-lo. Bugs
-  severos e problemas de segurança são constantemente encontrados durante o
-  processo de revisão. Isso é especialmente válido para código desenvolvido em
-  ambiente isolado; tais códigos se beneficiam fortemente ao serem revistos por
-  outros desenvolvedores. Código "out-of-tree" é código de baixa qualidade.
-
-- Participação no processo de desenvolvimento é a forma pela qual você pode
-  influenciar a direção do desenvolvimento do kernel. Usuários que se queixam
-  externamente são ouvidos, porém desenvolvedores ativos têm maior poder de
-  articulação - e a habilidade de implementar mudanças que façam o kernel
-  funcionar melhor para suas necessidades.
+- O código do kernel está sujeito a revisão, tanto antes como depois do merge
+  no "mainline". Por mais sólidas que sejam as habilidades do desenvolvedor
+  original, esse processo de revisão invariavelmente encontra maneiras de
+  melhorar o código. Com frequência, a revisão encontra bugs graves e problemas
+  de segurança. Isso é especialmente válido para código desenvolvido em
+  ambiente fechado; esse tipo de código se beneficia muito da revisão por
+  desenvolvedores externos. Código "out-of-tree" é código de qualidade
+  inferior.
+
+- A participação no processo de desenvolvimento é a forma pela qual você pode
+  influenciar a direção do desenvolvimento do kernel. Usuários que reclamam de
+  fora são ouvidos, mas desenvolvedores ativos têm uma voz mais forte - e a
+  capacidade de implementar mudanças que façam o kernel funcionar melhor para
+  suas necessidades.
 
 - Quando o código é mantido à parte, sempre existe a possibilidade de que
-  terceiros contribuam para uma implementação diferente de uma funcionalidade
-  parecida. Se isso acontecer, ter seu código integrado via merge se tornará
-  muito mais difícil - ao ponto de ser impossível. Você enfrentará duas
-  alternativas desagradáveis, (1) manter uma funcionalidade "out-of-tree"
-  indefinidamente ou (2) abandonar seu código e migrar seus usuários para a
-  versão na árvore principal ("in-tree").
-
-- Contribuição de código é a ação fundamental que faz todo o processo
-  funcionar. Ao contribuir com seu código você pode adicionar nova
-  funcionalidade ao kernel e proporcionar capacidades e exemplos que podem ser
-  usados por outros desenvolvedores de kernel. Se você desenvolveu código para
-  o Linux (ou está pensando em desenvolver), você claramente tem interesse na
-  continuidade do sucesso dessa plataforma; contribuição de código é uma das
-  melhores maneiras de garantir esse sucesso.
-
-Todos os argumentos acima se aplicam a qualquer código "out-of-tree", incluindo
-código distribuído de maneira proprietária, em formato exclusivamente binário.
-Existem fatores adicionais que devem ser levados em consideração antes de
-qualquer distribuição de código de kernel apenas em binário, incluindo:
-
-- As questões legais da distribuição de kernel proprietário são, no melhor dos
-  casos, confusas; muitos detentores de direitos autorais do kernel acreditam
-  que a maioria dos módulos binários são produtos derivados do kernel e que,
-  como resultado, sua distribuição é uma violação da Licença Pública Geral GNU
-  ("GNU General Public License"), que será tratada com mais profundidade abaixo.
-  Este autor não é um advogado, e nada neste documento pode ser considerado
-  aconselhamento jurídico. O verdadeiro status de módulos privados ("closed
-  source") só pode ser determinado judicialmente. Independentemente disso, a
-  incerteza que cerca esses módulos existe.
+  terceiros contribuam com uma implementação diferente de uma funcionalidade
+  parecida. Se isso acontecer, conseguir o merge do seu código se tornará muito
+  mais difícil - a ponto de ser impossível. Então você se verá diante das
+  alternativas desagradáveis de (1) manter indefinidamente uma funcionalidade
+  não padronizada "out-of-tree" ou (2) abandonar seu código e migrar seus
+  usuários para a versão na árvore principal ("in-tree").
+
+- A contribuição de código é a ação fundamental que faz todo o processo
+  funcionar. Ao contribuir com seu código, você pode adicionar novas
+  funcionalidades ao kernel e fornecer capacidades e exemplos úteis para outros
+  desenvolvedores do kernel. Se você desenvolveu código para o Linux (ou está
+  pensando em fazê-lo), você claramente tem interesse no sucesso contínuo dessa
+  plataforma; contribuir com código é uma das melhores maneiras de ajudar a
+  garantir esse sucesso.
+
+Todos os argumentos acima se aplicam a qualquer código de kernel "out-of-tree",
+incluindo código distribuído em formato proprietário e exclusivamente binário.
+Existem, no entanto, fatores adicionais que devem ser levados em conta antes de
+considerar qualquer tipo de distribuição de código de kernel exclusivamente
+binário. Entre eles:
+
+- As questões legais em torno da distribuição de módulos de kernel
+  proprietários são, no melhor dos casos, nebulosas; muitos detentores de
+  direitos autorais do kernel acreditam que a maioria dos módulos
+  exclusivamente binários são produtos derivados do kernel e que, como
+  resultado, sua distribuição é uma violação da Licença Pública Geral GNU ("GNU
+  General Public License"), que será tratada com mais profundidade abaixo. Este
+  autor não é advogado, e nada neste documento pode ser considerado
+  aconselhamento jurídico. O verdadeiro status jurídico dos módulos de código
+  fechado ("closed source") só pode ser determinado judicialmente.
+  Independentemente disso, a incerteza que cerca esses módulos existe.
 
 - Os módulos binários aumentam consideravelmente a dificuldade de depuração de
   problemas do kernel ("debugging"), a ponto de a maioria dos desenvolvedores
-  de kernel sequer tentar. Portanto, a distribuição de módulos exclusivamente
-  binários tornará mais difícil que os seus usuários recebam suporte.
+  de kernel nem sequer tentar. Portanto, a distribuição de módulos
+  exclusivamente binários tornará mais difícil que os seus usuários recebam
+  suporte da comunidade.
 
 - O suporte também é mais difícil para distribuidores de módulos exclusivamente
   binários, que precisam fornecer uma versão do módulo para cada distribuição e
-  cada versão do kernel que desejam suportar. Dezenas de versões de um único
-  módulo podem ser necessárias para fornecer uma cobertura razoavelmente
-  abrangente, e seus usuários terão que atualizar seu módulo separadamente
-  sempre que atualizarem seu kernel.
+  cada versão do kernel que desejam suportar. Dezenas de compilações ("builds")
+  de um único módulo podem ser necessárias para fornecer uma cobertura
+  razoavelmente abrangente, e seus usuários terão que atualizar seu módulo
+  separadamente sempre que atualizarem seu kernel.
 
 - Tudo o que foi dito acima sobre revisão de código se aplica em dobro ao
-  código fechado. Como esse código não está disponível, ele não pode ter sido
-  revisado pela comunidade e, sem dúvida, terá sérios problemas.
+  código fechado. Como esse código não está disponível de forma alguma, ele não
+  pode ter sido revisado pela comunidade e, sem dúvida, terá sérios problemas.
 
 Os fabricantes de sistemas embarcados, em particular, podem ser tentados a
 ignorar grande parte do que foi dito nesta seção, acreditando que estão
 lançando um produto autossuficiente que usa uma versão congelada do kernel e
 não requer mais desenvolvimento após o lançamento. Esse argumento ignora o
-valor de uma revisão de código abrangente e o valor de permitir que seus
-usuários adicionem recursos ao seu produto. Mas esses produtos também têm uma
-vida comercial limitada, após a qual uma nova versão deve ser lançada. Nesse
-ponto, os fornecedores cujo código está no "mainline" e bem mantido estarão em
-uma posição muito melhor para preparar o novo produto para o mercado
-rapidamente.
+valor de uma revisão de código ampla e o valor de permitir que seus usuários
+adicionem recursos ao seu produto. Mas esses produtos também têm uma vida
+comercial limitada, após a qual uma nova versão deve ser lançada. Nesse ponto,
+os fornecedores cujo código está no "mainline" e é bem mantido estarão em uma
+posição muito melhor para preparar rapidamente o novo produto para o mercado.
 
 Licenciamento
 -------------
 
-Código é submetido ao kernel do Linux sob diversas licenças, mas todo ele deve
+Código é contribuído ao kernel Linux sob diversas licenças, mas todo ele deve
 ser compatível com a versão 2 da Licença Pública Geral GNU (GPLv2), que é a
 licença que cobre a distribuição do kernel como um todo. Na prática, isso
 significa que todas as contribuições de código são cobertas pela GPLv2 (com,
-opcionalmente, uma linguagem que permita a distribuição sob versões posteriores
-da GPL) ou pela licença BSD de três cláusulas. Quaisquer contribuições que não
+opcionalmente, um texto que permita a distribuição sob versões posteriores da
+GPL) ou pela licença BSD de três cláusulas. Quaisquer contribuições que não
 sejam cobertas por uma licença compatível não serão aceitas no kernel.
 
 A cessão de direitos autorais não é exigida (nem solicitada) para o código
-contribuído para o kernel. Todo o código incorporado ao kernel principal mantém
-sua titularidade original; como resultado, o kernel agora tem milhares de
+contribuído ao kernel. Todo o código incorporado ao "mainline" mantém sua
+titularidade original; como resultado, o kernel agora tem milhares de
 proprietários.
 
 Uma implicação dessa estrutura de propriedade é que qualquer tentativa de
 alterar o licenciamento do kernel está fadada ao fracasso quase certo. Existem
 poucos cenários práticos em que o acordo de todos os detentores de direitos
 autorais poderia ser obtido (ou seu código removido do kernel). Portanto, em
-particular, não há perspectiva de migração para a versão 3 da GPL em um futuro
-próximo.
+particular, não há perspectiva de migração para a versão 3 da GPL no futuro
+previsível.
 
-É imprescindível que todo o código contribuído para o kernel seja legitimamente
+É imprescindível que todo o código contribuído ao kernel seja legitimamente
 software livre. Por esse motivo, código de contribuidores sem identidade
-conhecida ou contribuidores anônimos não será aceito. Todos os contribuidores
-são obrigados a "assinar" seu código, declarando que ele pode ser distribuído
-com o kernel sob a GPL. Código que não tenha sido licenciado como software
-livre por seu proprietário, ou que apresente risco de criar problemas
-relacionados a direitos autorais para o kernel (como código derivado de
-esforços de engenharia reversa sem as devidas salvaguardas) não pode ser
-contribuído.
+conhecida ou de contribuidores anônimos não será aceito. Todos os
+contribuidores são obrigados a "assinar" ("sign off") seu código, declarando
+que ele pode ser distribuído com o kernel sob a GPL. Código que não tenha sido
+licenciado como software livre por seu proprietário, ou que apresente risco de
+criar problemas relacionados a direitos autorais para o kernel (como código
+derivado de esforços de engenharia reversa sem as devidas salvaguardas), não
+pode ser contribuído.
 
 Questões sobre direitos autorais são comuns em listas de discussão de
 desenvolvimento Linux. Normalmente, essas perguntas recebem muitas respostas,
diff --git a/Documentation/translations/pt_BR/process/2.Process.rst b/Documentation/translations/pt_BR/process/2.Process.rst
index 0019b7404..a0b6decfa 100644
--- a/Documentation/translations/pt_BR/process/2.Process.rst
+++ b/Documentation/translations/pt_BR/process/2.Process.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_process:
+
 Como funciona o processo de desenvolvimento
 ===========================================
 
diff --git a/Documentation/translations/pt_BR/process/3.Early-stage.rst b/Documentation/translations/pt_BR/process/3.Early-stage.rst
index 86c228353..9d9513e5c 100644
--- a/Documentation/translations/pt_BR/process/3.Early-stage.rst
+++ b/Documentation/translations/pt_BR/process/3.Early-stage.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_early_stage:
+
 Planejamento em estágio inicial
 ===============================
 
diff --git a/Documentation/translations/pt_BR/process/4.Coding.rst b/Documentation/translations/pt_BR/process/4.Coding.rst
index 7c7567165..914a3d4c5 100644
--- a/Documentation/translations/pt_BR/process/4.Coding.rst
+++ b/Documentation/translations/pt_BR/process/4.Coding.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_coding:
+
 Escrever o código corretamente
 ==============================
 
diff --git a/Documentation/translations/pt_BR/process/5.Posting.rst b/Documentation/translations/pt_BR/process/5.Posting.rst
index 2ac7e5557..60e12c1ee 100644
--- a/Documentation/translations/pt_BR/process/5.Posting.rst
+++ b/Documentation/translations/pt_BR/process/5.Posting.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_posting:
+
 Enviando patches
 ================
 
diff --git a/Documentation/translations/pt_BR/process/6.Followthrough.rst b/Documentation/translations/pt_BR/process/6.Followthrough.rst
index dbdf479bb..c016f9e57 100644
--- a/Documentation/translations/pt_BR/process/6.Followthrough.rst
+++ b/Documentation/translations/pt_BR/process/6.Followthrough.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_followthrough:
+
 Acompanhamento
 ==============
 
diff --git a/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst b/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst
index 97466fad1..bd98927c4 100644
--- a/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_advancedtopics:
+
 Tópicos avançados
 =================
 
diff --git a/Documentation/translations/pt_BR/process/8.Conclusion.rst b/Documentation/translations/pt_BR/process/8.Conclusion.rst
index 2696ea167..6691627b2 100644
--- a/Documentation/translations/pt_BR/process/8.Conclusion.rst
+++ b/Documentation/translations/pt_BR/process/8.Conclusion.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_development_conclusion:
+
 Para mais informações
 =====================
 
-- 
2.47.3

[PATCH 02/11] docs/translations/pt_BR: process: coding-assistants.rst: add bug procedure

[Daniel Pereira]

Sync with the English version: translate the new "Procedure for
finding and fixing bugs" section, which lists the steps an AI assistant
must follow when finding and fixing bugs.

Also fix two translation errors: "GPL-2.0-only" is the license
identifier, not "only GPL-2.0", and the generated-content.rst pointer is
about guidelines on content generated by AI assistants, not only about
code.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/coding-assistants.rst       | 45 ++++++++++++++++++-
 1 file changed, 43 insertions(+), 2 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/coding-assistants.rst b/Documentation/translations/pt_BR/process/coding-assistants.rst
index f6062b22a..906dc880e 100644
--- a/Documentation/translations/pt_BR/process/coding-assistants.rst
+++ b/Documentation/translations/pt_BR/process/coding-assistants.rst
@@ -13,7 +13,7 @@ padrões de desenvolvimento do kernel:
 * Documentation/process/coding-style.rst
 * Documentation/process/submitting-patches.rst
 
-Para guias e conteúdo sobre códigos gerados por assistentes de IA veja:
+Para diretrizes sobre conteúdo gerado por assistentes de IA, veja:
 
 * Documentation/process/generated-content.rst
 
@@ -23,7 +23,7 @@ Licenças e Requisitos Legais
 Todas as contribuições devem estar de acordo com os requisitos de licença do
 kernel:
 
-* Todo código deve ser compatível apenas com GPL-2.0
+* Todo código deve ser compatível com GPL-2.0-only
 * Use identificadores SPDX de licença apropriados
 * Veja Documentation/process/license-rules.rst para mais detalhes
 
@@ -38,3 +38,44 @@ A pessoa que envia é responsável por:
 * Garantir conformidade com os requisitos de licença
 * Acrescentar sua própria tag Signed-off-by para certificar o DCO
 * Assumir toda responsabilidade pela contribuição
+
+Procedimento para encontrar e corrigir bugs
+===========================================
+
+Quando um assistente de IA é usado para encontrar e corrigir bugs, ele **DEVE**
+seguir pelo menos estes passos:
+
+1. Antes de começar, leia toda a documentação do processo listada acima, bem
+   como qualquer outro documento mencionado na solicitação. Não confie em
+   trechos isolados encontrados por busca de palavras-chave.
+2. Anote o ID do commit e localize um bug conforme instruído.
+3. Para qualquer bug encontrado que não seja trivial, verifique se ele parece
+   real tentando criar um reprodutor que o demonstre. A falta dele pode fazer
+   com que o relatório seja ignorado, já que muitos relatórios de bugs não
+   verificados enviados aos mantenedores acabam sendo inválidos. Pare aqui se,
+   no fim, ele parecer equivocado.
+4. Escreva uma correção para o bug. Esta parte não é opcional: exceto em
+   alguns poucos casos muito raros, um assistente de IA capaz de encontrar um
+   bug é capaz de corrigi-lo. Note que correções escritas na mesma sessão
+   usada para encontrar o bug geralmente resultam em correções melhores e mais
+   precisas, pois o contexto de raciocínio do LLM continua presente.
+5. Compile e verifique se a correção funciona, usando o reprodutor ou
+   executando novamente uma análise completa; descarte qualquer correção que
+   não funcione e tente outra. A correção não deve adicionar avisos de
+   compilação e deve passar nas verificações do checkpatch.pl (veja
+   submitting-patches.rst).
+6. Faça o commit da correção que funciona com uma mensagem detalhada
+   descrevendo o problema, a solução e uma tag Fixes. Não adicione uma tag
+   Signed-off-by.
+7. Identifique os mantenedores e as listas usando scripts/get_maintainer.pl.
+   Documentation/process/security-bugs.rst mostra como fazer isso.
+8. Indique o que não pôde ser feito. Se a correção não pôde ser compilada ou
+   testada, ou se não foi possível produzir um reprodutor, diga isso
+   explicitamente: atualmente os mantenedores perdem tempo demais analisando
+   relatórios não verificados e correções não testadas.
+9. Leia Documentation/process/threat-model.rst para determinar se o bug é uma
+   vulnerabilidade ou um bug comum, e deixe o resultado para a revisão do
+   relator (o assistente nunca deve enviar nada por conta própria). Bugs
+   comuns são enviados conforme descrito em
+   Documentation/process/submitting-patches.rst, e vulnerabilidades conforme
+   descrito em Documentation/process/security-bugs.rst.
-- 
2.47.3

[PATCH 03/11] docs/translations/pt_BR: process: security-bugs.rst: sync with English

[Daniel Pereira]

Sync with the English version:

- the report must give the affected kernel version range using a stable
  identifier (commit ID or exact version); time-dependent versions and
  distro kernel versions are not accepted;
- add the closing part of the "Responsible use of AI to find bugs"
  section, with the minimum procedure an AI assistant must follow and
  the two mandatory report steps.

Also fix the "reproducer" labels, translated as a verb and as a word
that does not exist in Portuguese, restore the "instead" that was
dropped and the bold emphasis lost in four places.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/security-bugs.rst           | 53 ++++++++++++++-----
 1 file changed, 41 insertions(+), 12 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/security-bugs.rst b/Documentation/translations/pt_BR/process/security-bugs.rst
index 321575657..dac456f6e 100644
--- a/Documentation/translations/pt_BR/process/security-bugs.rst
+++ b/Documentation/translations/pt_BR/process/security-bugs.rst
@@ -20,8 +20,13 @@ você não tiver certeza sobre quais informações são úteis. As seguintes
 informações são absolutamente necessárias em **qualquer** relatório de falha de
 segurança:
 
-  * **versão do kernel afetada**: sem indicação de versão, seu relatório não
-    será processado. Uma parte significativa dos relatórios é de bugs que já
+  * **intervalo de versões do kernel afetadas**: sem indicação de versão, seu
+    relatório não será processado. Observe que uma versão dependente do tempo,
+    como "o mainline mais recente", não é aceitável. É necessário um
+    identificador estável, como o ID de um commit ou uma versão exata. Versões
+    que designam kernels que não vêm do kernel.org (como kernels de
+    distribuições) não têm significado para os mantenedores e não serão
+    processadas. Uma parte significativa dos relatórios é de bugs que já
     foram corrigidos, portanto, é extremamente importante que as
     vulnerabilidades sejam verificadas em versões recentes (árvore de
     desenvolvimento ou a versão estável mais recente), pelo menos verificando
@@ -31,7 +36,7 @@ segurança:
     mostrando sua manifestação, e por que você considera o comportamento
     observado como um problema no Kernel, é necessária.
 
-  * **reproduzir**: os desenvolvedores precisarão ser capazes de reproduzir o
+  * **reprodutor**: os desenvolvedores precisarão ser capazes de reproduzir o
     problema para considerar uma correção como eficaz. Isso inclui tanto uma
     maneira de acionar o problema quanto uma maneira de confirmar que ele
     ocorre. Será necessário um reprodutor com dependências de baixa
@@ -87,7 +92,7 @@ apenas bugs comuns que foram qualificados incorretamente como bugs de segurança
 devido à falta de conhecimento do modelo de ameaças do kernel Linux, conforme
 descrito em Documentation/process/threat-model.rst, e deveriam ter sido
 enviados através dos canais normais descritos em
-Documentation/admin-guide/reporting-issues.rst
+Documentation/admin-guide/reporting-issues.rst, em vez disso.
 
 A lista de segurança existe para bugs urgentes que concedem a um atacante uma
 capacidade que ele não deveria ter em um sistema de produção corretamente
@@ -175,7 +180,7 @@ ou este para a lista mais ampla::
   dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
 
 Se a esta altura você ainda estiver enfrentando dificuldades para identificar
-os mantenedores corretos, e apenas neste caso, é possível enviar seu
+os mantenedores corretos, **e apenas neste caso**, é possível enviar seu
 relatório apenas para a equipe de segurança do kernel Linux. Sua mensagem
 será triada e você receberá instruções sobre quem contatar, se necessário.
 Sua mensagem poderá igualmente ser encaminhada como está para os mantenedores
@@ -203,8 +208,8 @@ a tornar esses relatórios desnecessariamente difíceis de lidar:
   * **Formatação**: A maioria dos relatórios gerados por IA está repleta de
     tags Markdown. Essas decorações complicam a busca por informações
     importantes e não sobrevivem aos processos de citação envolvidos no
-    encaminhamento ou nas respostas. Por favor, sempre converta seu relatório
-    para texto simples sem quaisquer decorações de formatação antes de
+    encaminhamento ou nas respostas. Por favor, **sempre converta seu relatório
+    para texto simples** sem quaisquer decorações de formatação antes de
     enviá-lo.
 
   * **Avaliação de Impacto**: Muitos relatórios gerados por IA carecem de uma
@@ -216,17 +221,17 @@ a tornar esses relatórios desnecessariamente difíceis de lidar:
     especulativas. Faça com que sua ferramenta leia esta documentação como
     parte do processo de avaliação.
 
-  * **Reproduzidor**: As ferramentas baseadas em IA são frequentemente capazes
-    de gerar reproduzidores. Por favor, certifique-se sempre de que sua
-    ferramenta forneça um e teste-o exaustivamente. Se o reproduzidor não
+  * **Reprodutor**: As ferramentas baseadas em IA são frequentemente capazes
+    de gerar reprodutores. Por favor, certifique-se sempre de que sua
+    ferramenta forneça um e **teste-o exaustivamente**. Se o reprodutor não
     funcionar, ou se a ferramenta não puder produzir um, a validade do
     relatório deve ser seriamente questionada. Observe que, como o relatório
-    será postado em uma lista pública, o reproduzidor só deve ser compartilhado
+    será postado em uma lista pública, o reprodutor só deve ser compartilhado
     mediante solicitação dos mantenedores.
 
   * **Propor uma Correção:** muitas ferramentas de IA são na verdade melhores
     em escrever código do que em avaliá-lo. Por favor, peça à sua ferramenta
-    para propor uma correção e teste-a antes de relatar o problema.
+    para propor uma correção e **teste-a** antes de relatar o problema.
     Se a correção não puder ser testada porque depende de hardware raro ou de
     protocolos de rede quase extintos, é provável que o problema não seja um
     bug de segurança. Em qualquer caso, se uma correção for proposta, ela deve
@@ -245,6 +250,30 @@ um mantenedor com um relatório sem importância. Se o problema for claramente
 trivial e publicamente detectável, você deve relatá-lo diretamente às listas
 de discussão públicas.
 
+No mínimo, ao usar um assistente de IA para encontrar e relatar bugs, faça com
+que o assistente leia este arquivo e o Documentation/process/threat-model.rst
+antes de prosseguir, e que ele siga o procedimento descrito em
+coding-assistants.rst: trabalhar em uma árvore mainline atualizada e anotar o
+ID do commit, verificar se o bug é real, escrever uma correção, compilá-la sem
+avisos e sem apontamentos do checkpatch, fazer o commit com uma tag Fixes e
+identificar os mantenedores com o get_maintainer.pl.
+
+Além desse procedimento, o assistente de IA **DEVE**:
+
+1. Preparar um relatório em texto simples explicando o problema. Ele deve
+   conter os quatro itens listados no topo deste arquivo como absolutamente
+   necessários: a versão afetada ou o ID do commit anotado ao seguir o
+   procedimento acima, a descrição do problema, o reprodutor ou o seu status,
+   e as condições de acionamento.
+2. Iniciar o relatório com uma seção temporária listando os endereços dos
+   destinatários (mantenedores+lista para o patch, apenas mantenedores para o
+   relatório e o reprodutor), e com instruções lembrando o relator de verificar
+   se o seu cliente de e-mail está configurado corretamente (veja
+   email-clients.rst), e deixar a cargo do relator a remoção dessa seção
+   temporária.
+
+Um processo mais detalhado é descrito em https://github.com/masoncl/kres.git.
+
 Enviando o relatório
 --------------------
 
-- 
2.47.3

[PATCH 04/11] docs/translations/pt_BR: process: maintainer-netdev.rst: sync with English

[Daniel Pereira]

Sync with the English version: translate the paragraphs about the
LLM-generated reviews (Sashiko) and about not contacting maintainers or
reviewers through private channels.

Also fix errors against the English text:

- "We give no guarantees that netdevsim won't change" had its negation
  inverted;
- "eventually" was translated with the false friend "eventualmente";
- restore "process issues", "~10 weeks", the dash in the RFC paragraph
  and "xmas" in "reverse xmas tree";
- "Updating patch status" was a section instead of a subsection;
- two inline literals were not closed properly and rendered with
  visible backquotes;
- add a missing space after a semicolon in the tl;dr and remove a
  doubled space in the example reply;
- restore the links to the patch status, local variable ordering,
  stable kernel rules, submitting patches and patch review sections,
  adding the pt_BR_patch_status, pt_BR_rcs and
  pt_BR_development_advancedtopics_reviews labels, which mirror the
  English ones.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/7.AdvancedTopics.rst        |  2 +
 .../pt_BR/process/maintainer-netdev.rst       | 76 +++++++++++++------
 2 files changed, 54 insertions(+), 24 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst b/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst
index bd98927c4..bbf0c733a 100644
--- a/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/pt_BR/process/7.AdvancedTopics.rst
@@ -154,6 +154,8 @@ esperam e também verificará se você se lembrou de dar push nessas alteraçõe
 para o servidor público.
 
 
+.. _pt_BR_development_advancedtopics_reviews:
+
 Revisão de patches
 ------------------
 
diff --git a/Documentation/translations/pt_BR/process/maintainer-netdev.rst b/Documentation/translations/pt_BR/process/maintainer-netdev.rst
index e9bb998c7..2f90bd93e 100644
--- a/Documentation/translations/pt_BR/process/maintainer-netdev.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-netdev.rst
@@ -7,11 +7,11 @@ Subsistema de Rede do Linux (netdev)
 tl;dr
 -----
 
-- **Direcione seu patch para uma árvore** – use ``[PATCH net]``para correções
+- **Direcione seu patch para uma árvore** – use ``[PATCH net]`` para correções
   ou ``[PATCH net-next]`` para novas funcionalidades.
 - **Tag Fixes** – para correções, a tag ``Fixes:`` é obrigatória,
   independentemente da árvore de destino.
-- **Tamanho da série** – não envie séries grandes (> 15 patches);divida-as em
+- **Tamanho da série** – não envie séries grandes (> 15 patches); divida-as em
   partes menores.
 - **Intervalo de envio** – não reenvie seus patches dentro de um período de 24
   horas.
@@ -70,7 +70,7 @@ mesclagem (*merge window*) e o ``net-next`` está fechado.
 ------------------------------
 
 Existem duas árvores de rede (repositórios git) em jogo. Ambas são coordenadas
-por David Miller, o mantenedor principal de rede. Há a árvore ``net``e a árvore
+por David Miller, o mantenedor principal de rede. Há a árvore ``net`` e a árvore
 ``net-next``. Como você provavelmente pode adivinhar pelos nomes, a árvore
 ``net`` é para correções de código existente já na árvore mainline de Linus, e a
 ``net-next`` é para onde o novo código vai para o lançamento futuro.
@@ -81,7 +81,7 @@ Você pode encontrar as árvores aqui:
 
 Relacionando isso ao desenvolvimento do kernel: no início da janela de mesclagem
 (*merge window*) de 2 semanas, a árvore ``net-next`` será fechada, sem novas
-mudanças ou funcionalidades. O conteúdo novo acumulado nas últimas 10 semanas
+mudanças ou funcionalidades. O conteúdo novo acumulado nas últimas ~10 semanas
 será passado para a mainline/Linus via um *pull request* para a vX.Y ao mesmo
 tempo, a árvore ``net`` começará a acumular correções para este conteúdo enviado
 relacionado à vX.Y.
@@ -118,6 +118,8 @@ Finalmente, a vX.Y é lançada e todo o ciclo recomeça.
 Revisão de patches da netdev
 ----------------------------
 
+.. _pt_BR_patch_status:
+
 Status do patch
 ~~~~~~~~~~~~~~~
 
@@ -168,7 +170,7 @@ transportaram; portanto, se você tiver problemas para encontrar seu patch,
 anexe o valor do ``Message-ID`` à URL acima.
 
 Atualizando o status do patch
------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Colaboradores e revisores não têm permissões para atualizar o estado do patch
 diretamente no patchwork. O Patchwork não expõe muitas informações sobre o
@@ -216,26 +218,48 @@ comentários e respostas cheguem após uma semana de silêncio. Se um
 patch não estiver mais ativo no patchwork e a thread ficar inativa por mais de
 uma semana - esclareça os próximos passos e/ou envie a próxima versão.
 
-Especificamente para envios de RFC, se ninguém responder em uma semana  ou os
+Especificamente para envios de RFC, se ninguém responder em uma semana - ou os
 revisores perderam o envio ou não têm opiniões fortes a respeito. Se o código
 estiver pronto, reenvie como um PATCH.
 
+Há 2 serviços que fornecem ativamente revisões geradas por LLM para os patches
+enviados:
+
+- https://sashiko.dev/
+- https://netdev-ai.bots.linux.dev/sashiko/
+
+ambos usam a infraestrutura do Sashiko sobre modelos diferentes. As revisões
+ficam disponíveis após 24h. Espera-se que os autores dos patches analisem
+proativamente as revisões geradas por IA e tratem esse feedback como qualquer
+outro tipo de revisão: discutindo-o ou atendendo-o. Em ambos os casos, espera-se
+uma resposta na lista de discussão.
+
+Os autores são fortemente encorajados a executar revisões por LLM nos patches
+antes de enviá-los de fato. Séries grandes que gerem uma quantidade
+significativa de feedback gerado por IA provavelmente receberão pouca atenção
+dos mantenedores e revisores.
+
 E-mails dizendo apenas "ping" ou "bump" são considerados rudes. Se você não
 conseguir identificar o status do patch pelo patchwork ou onde a discussão
 parou - descreva sua melhor suposição e pergunte se ela está correta. Por
 exemplo::
 
-  Não entendo quais são os próximos passos. A Pessoa X parece estar  descontente
+  Não entendo quais são os próximos passos. A Pessoa X parece estar descontente
   com A; devo fazer B e enviar novamente os patches?
 
+Não entre em contato com mantenedores ou revisores por e-mail privado e/ou
+outros canais de comunicação: toda a discussão deve permanecer pública, e pedir
+atenção especial é, na melhor das hipóteses, injusto com a comunidade.
+
 .. _Solicitações de mudanças:
 
 Mudanças solicitadas
 ~~~~~~~~~~~~~~~~~~~~
 
-Patches marcados como ``Changes Requested`` precisam ser revisados. A nova
-versão deve vir com um registro de alterações (changelog),
-preferencialmente incluindo links para as postagens anteriores, por exemplo::
+Patches :ref:`marcados<pt_BR_patch_status>` como ``Changes Requested``
+precisam ser revisados. A nova versão deve vir com um registro de alterações
+(changelog), preferencialmente incluindo links para as postagens anteriores,
+por exemplo::
 
   [PATCH net-next v3] net: faz as vacas dizerem "muuu"
 
@@ -292,8 +316,8 @@ incrementais são preferidas.
 Embora antigamente as submissões para a netdev não devessem carregar tags
 explícitas ``CC: stable@vger.kernel.org``, esse não é mais o caso hoje em dia.
 Por favor, siga as regras padrão de estabilidade em
-``Documentation/process/stable-kernel-rules.rst``, e certifique-se de incluir as
-tags Fixes apropriadas!
+:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
+e certifique-se de incluir as tags Fixes apropriadas!
 
 Correções de segurança
 ~~~~~~~~~~~~~~~~~~~~~~
@@ -359,7 +383,8 @@ Se for o seu primeiro patch, envie-o para si mesmo por e-mail para que você
 possa testar a aplicação em uma árvore sem patches para confirmar que a
 infraestrutura não o danificou.
 
-Finalmente, volte e leia ``Documentation/process/submitting-patches.rst``
+Finalmente, volte e leia
+:ref:`Documentation/process/submitting-patches.rst <pt_BR_submittingpatches>`
 para ter certeza de que não está repetindo algum erro comum documentado lá.
 
 Indicando a árvore de destino
@@ -399,8 +424,10 @@ Este limite tem o objetivo de focar o esforço do desenvolvedor nos testes dos
 patches antes da revisão upstream, auxiliando a qualidade das submissões
 upstream e aliviando a carga sobre os revisores.
 
-Ordenação de variáveis locais ("árvore invertida", "RCS")
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. _pt_BR_rcs:
+
+Ordenação de variáveis locais ("árvore de Natal invertida", "RCS")
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A netdev tem uma convenção para ordenar variáveis locais em funções. Ordene as
 linhas de declaração de variáveis da mais longa para a mais curta, por exemplo::
@@ -416,7 +443,7 @@ Precedência de formatação
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Ao trabalhar em código existente que utiliza formatação não padrão, faça com
-que seu código siga as diretrizes mais recentes, para que, eventualmente,
+que seu código siga as diretrizes mais recentes, para que, com o tempo,
 todo o código no domínio da netdev esteja no formato preferido.
 
 Uso de construções gerenciadas por dispositivo e cleanup.h
@@ -445,7 +472,7 @@ contexto de outro trabalho. Por exemplo:
 
 * Tratar avisos do ``checkpatch.pl`` e outros avisos triviais de estilo de
   codificação
-* Tratar problemas de Ordenação de variáveis locais
+* Tratar problemas de :ref:`Ordenação de variáveis locais<pt_BR_rcs>`
 * Conversões para APIs gerenciadas por dispositivo (auxiliares ``devm_``)
 
 Isso ocorre porque se considera que a agitação (*churn*) que tais mudanças
@@ -516,10 +543,11 @@ falha no núcleo que são difíceis de exercitar com um driver real.
 ``netdevsim`` em si **não** é considerado um caso de uso/usuário.
 Você também deve implementar as novas APIs em um driver real.
 
-Não damos garantias de que o ``netdevsim`` mudará no futuro de uma forma que
-quebraria o que normalmente seria considerado uAPI.  O ``netdevsim`` é reservado
-apenas para uso por testes upstream, portanto, quaisquer novos recursos do
-``netdevsim`` devem ser acompanhados de selftests em ``tools/testing/selftests/``.
+Não damos garantias de que o ``netdevsim`` não mudará no futuro de uma forma
+que quebraria o que normalmente seria considerado uAPI. O ``netdevsim`` é
+reservado apenas para uso por testes upstream, portanto, quaisquer novos
+recursos do ``netdevsim`` devem ser acompanhados de selftests em
+``tools/testing/selftests/``.
 
 Status de suporte para drivers
 ------------------------------
@@ -579,7 +607,7 @@ Orientações para revisores
 
 Revisar patches de outras pessoas na lista é altamente incentivado,
 independentemente do nível de experiência. Para orientações gerais e dicas
-úteis, consulte `revisão de tópicos avançados de desenvolvimento`.
+úteis, consulte :ref:`pt_BR_development_advancedtopics_reviews`.
 
 É seguro assumir que os mantenedores da netdev conhecem a comunidade e o nível
 de experiência dos revisores. Os revisores não devem se preocupar com o fato de
@@ -588,8 +616,8 @@ seus comentários impedirem ou desviarem o fluxo de patches. Uma tag Reviewed-by
 "Posso atestar que este código está correto".
 
 Revisores são fortemente incentivados a fazer uma revisão mais aprofundada das
-submissões e não focar exclusivamente em questões triviais ou subjetivas, como
-formatação de código, tags, etc.
+submissões e não focar exclusivamente em questões de processo, triviais ou
+subjetivas, como formatação de código, tags, etc.
 
 Depoimentos / feedback
 ----------------------
-- 
2.47.3

[PATCH 05/11] docs/translations/pt_BR: process: maintainer-soc.rst: sync with English

[Daniel Pereira]

Sync with the English version: replace the sentence about contacting the
devicetree maintainers, which is no longer in the original, with the new
paragraph about scripts/dtc/dt-check-style warnings.

Also fix errors against the English text: restore "upstream" in
"upstream-supported machine/board", translate "named after the vendor"
correctly, fix a list item whose continuation line started a new item,
and drop the literal markup around three document paths so that they
are turned into links as in the original.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/maintainer-soc.rst          | 20 ++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index eb8040a62..e98c8fcc1 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -14,7 +14,7 @@ O subsistema SoC é um local de agregação para códigos específicos de SoC
 * Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
 * Defconfigs ARM de 32 e 64 bits.
 * Drivers específicos de SoC em diversas arquiteturas, em particular para ARM de
-* 32 e 64 bits, RISC-V e Loongarch.
+  32 e 64 bits, RISC-V e Loongarch.
 
 Estes "drivers específicos de SoC" não incluem drivers de clock, GPIO, etc., que
 possuem outros mantenedores de alto nível. O diretório ``drivers/soc/`` é
@@ -102,7 +102,7 @@ Estabilidade da ABI do Devicetree
 
 Talvez um dos pontos mais importantes a destacar é que os *dt-bindings*
 documentam a ABI entre o devicetree e o kernel. Por favor, leia
-``Documentation/devicetree/bindings/ABI.rst``.
+Documentation/devicetree/bindings/ABI.rst.
 
 Se estiverem sendo feitas alterações em um DTS que sejam incompatíveis com
 kernels antigos, o patch do DTS não deve ser aplicado até que o driver seja, ou
@@ -163,7 +163,7 @@ Algumas plataformas também possuem *System on Modules* (SoM), contendo um SoC,
 que são então integrados em diversas placas diferentes. Para essas plataformas,
 ``$soc-$som.dtsi`` e ``$soc-$som-$board.dts`` são típicos.
 
-Os diretórios geralmente são nomeados após o fornecedor do SoC no momento de sua
+Os diretórios geralmente recebem o nome do fornecedor do SoC no momento de sua
 inclusão, o que leva a alguns nomes de diretórios históricos na árvore.
 
 Validando Arquivos de Devicetree
@@ -171,14 +171,16 @@ Validando Arquivos de Devicetree
 
 ``make dtbs_check`` pode ser usado para validar se os arquivos de devicetree
 estão em conformidade com os *dt-bindings* que descrevem a ABI. Por favor, leia
-a seção "Running checks" de ``Documentation/devicetree/bindings/writing-schema.rst``
+a seção "Running checks" de Documentation/devicetree/bindings/writing-schema.rst
 para mais informações sobre a validação de devicetrees.
 
 Para novas plataformas, ou adições a plataformas existentes, ``make dtbs_check``
 não deve adicionar nenhum aviso (*warning*) novo. Para SoCs RISC-V e Samsung, é
 exigido que ``make dtbs_check W=1`` não adicione nenhum novo aviso.
-Se houver qualquer dúvida sobre uma alteração de devicetree, entre em contato
-com os mantenedores de devicetree.
+
+Além disso, código novo não deve ter nenhum aviso do
+``scripts/dtc/dt-check-style`` no modo 'relaxed' e deve ter resolvido a maioria
+dos avisos no modo 'strict' (este último modo pode produzir falsos positivos).
 
 Branches e Pull Requests
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -219,7 +221,7 @@ melhor do que tentar combinar muitos patches em um único pull request.
 A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
 usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
 descrição resumindo as alterações no pull request. Para mais detalhes sobre o
-envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+envio de pull requests, consulte Documentation/maintainer/pull-requests.rst.
 
 Propósito dos Defconfigs
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -228,5 +230,5 @@ Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
 distribuições têm suas próprias configurações. Uma mudança que adiciona novas
 opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
 em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
-suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
-para máquinas não upstream não deve ser aceito.
+suportada no upstream usando essa nova opção. Isso implica que habilitar
+opções em defconfig para máquinas não upstream não deve ser aceito.
-- 
2.47.3

[PATCH 06/11] docs/translations/pt_BR: process: changes.rst: sync with English

[Daniel Pereira]

Sync the minimal requirements table with the English version: rows are
now sorted alphabetically, pahole requires 1.26, and the GRUB, GNU awk
and Sphinx entries follow the original spelling.

Also restore the third item of the JFSutils list, which had become a
paragraph, the reference to the sphinx_install section and the bold
emphasis on "least".

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../translations/pt_BR/process/changes.rst    | 61 ++++++++++---------
 1 file changed, 31 insertions(+), 30 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/changes.rst b/Documentation/translations/pt_BR/process/changes.rst
index 51c7fe416..3359e5ecd 100644
--- a/Documentation/translations/pt_BR/process/changes.rst
+++ b/Documentation/translations/pt_BR/process/changes.rst
@@ -18,7 +18,7 @@ Mauch, Axel Boldt, Alessandro Sigala e inúmeros outros usuários em toda a rede
 Requisitos Mínimos Atuais
 ****************************
 
-Atualize para pelo menos estas revisões de software antes de pensar que
+Atualize para pelo **menos** estas revisões de software antes de pensar que
 encontrou um bug! Se não tiver certeza de qual versão está executando atualmente
 , o comando sugerido deve lhe informar. Para uma lista dos programas em seu
 sistema, incluindo as versões, execute ./scripts/ver_linux.
@@ -31,41 +31,41 @@ PC Card por exemplo, provavelmente não precisará se preocupar com o pcmciautil
 ====================== ===============  ========================================
 Programa               Versão mínima    Comando para verificar a versão
 ====================== ===============  ========================================
-GNU C                  8.1              gcc --version
-Clang/LLVM (optional)  17.0.1           clang --version
-Rust (optional)        1.85.0           rustc --version
-bindgen (optional)     0.71.1           bindgen --version
-GNU make               4.0              make --version
 bash                   4.2              bash --version
+bc                     1.06.95          bc --version
+bindgen (optional)     0.71.1           bindgen --version
 binutils               2.30             ld -v
-flex                   2.5.35           flex --version
-gdb                    7.2              gdb --version
 bison                  2.0              bison --version
-pahole                 1.22             pahole --version
-util-linux             2.10o            mount --version
-kmod                   13               kmod -V
+btrfs-progs            0.18             btrfs --version
+Clang/LLVM (optional)  17.0.1           clang --version
 e2fsprogs              1.41.4           e2fsck -V
+flex                   2.5.35           flex --version
+gdb                    7.2              gdb --version
+GNU awk (opcional)     5.1.0            gawk --version
+GNU C                  8.1              gcc --version
+GNU make               4.0              make --version
+GNU tar                1.28             tar --version
+GRUB                   0.93             grub --version || grub-install --version
+gtags (opcional)       6.6.5            gtags --version
+iptables               1.4.2            iptables -V
 jfsutils               1.1.3            fsck.jfs -V
-xfsprogs               2.6.0            xfs_db -V
-squashfs-tools         4.0              mksquashfs -version
-btrfs-progs            0.18             btrfs --version
+kmod                   13               kmod -V
+mcelog                 0.6              mcelog --version
+mkimage (opcional)     2017.01          mkimage --version
+nfs-utils              1.0.5            showmount --version
+openssl & libcrypto    1.0.0            openssl version
+pahole                 1.26             pahole --version
 pcmciautils            004              pccardctl -V
-quota-tools            3.09             quota -V
 PPP                    2.4.0            pppd --version
-nfs-utils              1.0.5            showmount --version
 procps                 3.2.0            ps --version
-udev                   081              udevadm --version
-grub                   0.93             grub --version || grub-install --version
-mcelog                 0.6              mcelog --version
-iptables               1.4.2            iptables -V
-openssl & libcrypto    1.0.0            openssl version
-bc                     1.06.95          bc --version
-Sphinx [#f1]_          3.4.3            sphinx-build --version
-GNU tar                1.28             tar --version
-gtags (opcional)       6.6.5            gtags --version
-mkimage (opcional)     2017.01          mkimage --version
 Python                 3.9.x            python3 --version
-GNU AWK (opcional)     5.1.0            gawk --version
+quota-tools            3.09             quota -V
+Rust (optional)        1.85.0           rustc --version
+Sphinx\ [#f1]_         3.4.3            sphinx-build --version
+squashfs-tools         4.0              mksquashfs -version
+udev                   081              udevadm --version
+util-linux             2.10o            mount --version
+xfsprogs               2.6.0            xfs_db -V
 ====================== ===============  ========================================
 
 .. [#f1] O Sphinx é necessário apenas para gerar a documentação do Kernel.
@@ -272,7 +272,8 @@ utilitários estão disponíveis:
 
 - ``mkfs.jfs`` - cria uma partição formatada em JFS.
 
-Outros utilitários de sistema de arquivos também estão disponíveis neste pacote.
+- outros utilitários de sistema de arquivos também estão disponíveis neste
+  pacote.
 
 Xfsprogs
 --------
@@ -399,8 +400,8 @@ Documentação do Kernel
 Sphinx
 ------
 
-Por favor, consulte Documentation/doc-guide/sphinx.rst para detalhes sobre os
-requisitos do Sphinx.
+Por favor, consulte :ref:`sphinx_install` em Documentation/doc-guide/sphinx.rst
+para detalhes sobre os requisitos do Sphinx.
 
 rustdoc
 -------
-- 
2.47.3

[PATCH 07/11] docs/translations/pt_BR: process: license-rules.rst: fix lists and table

[Daniel Pereira]

The license identifier categories were numbered 4 to 7 instead of 1 to
4, the first paragraph of the "Exceptions" item was not indented and
rendered as a definition list, a duplicated "File format examples" line
broke the list, and the MODULE_LICENSE() table was rendered as a literal
block. Fix them to match the English version.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/license-rules.rst            | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/license-rules.rst b/Documentation/translations/pt_BR/process/license-rules.rst
index 7a801b2a4..3cbc1dccb 100644
--- a/Documentation/translations/pt_BR/process/license-rules.rst
+++ b/Documentation/translations/pt_BR/process/license-rules.rst
@@ -155,7 +155,7 @@ Identificadores de Licença
 As licenças atualmente em uso, bem como as licenças para código adicionado ao
 kernel, podem ser divididas em:
 
-4. _`Licenças preferenciais`:
+1. _`Licenças preferenciais`:
 
    Sempre que possível, estas licenças devem ser utilizadas, pois são conhecidas
    por serem totalmente compatíveis e amplamente usadas. Estas licenças estão
@@ -234,7 +234,7 @@ kernel, podem ser divididas em:
       License-Text:
         Texto completo da licença
 
-5. Licenças obsoletas:
+2. Licenças obsoletas:
 
    Estas licenças devem ser utilizadas apenas para código já existente ou para
    a importação de código de outros projetos. Estas licenças estão disponíveis
@@ -279,7 +279,7 @@ kernel, podem ser divididas em:
       License-Text:
         Texto completo da licença
 
-6. Apenas Licenciamento Duplo
+3. Apenas Licenciamento Duplo
 
    Estas licenças devem ser usadas apenas para o licenciamento duplo de código
    com outra licença, além de uma licença preferencial. Estas licenças estão
@@ -329,11 +329,11 @@ kernel, podem ser divididas em:
 
 |
 
-7. _`Exceções`:
+4. _`Exceções`:
 
-Algumas licenças podem ser alteradas com exceções que concedem certos direitos
-   que a licença original não concede. Estas exceções estão disponíveis no
-   diretório::
+   Algumas licenças podem ser alteradas com exceções que concedem certos
+   direitos que a licença original não concede. Estas exceções estão
+   disponíveis no diretório::
 
       LICENSES/exceptions/
 
@@ -402,7 +402,7 @@ Algumas licenças podem ser alteradas com exceções que concedem certos direito
       Exception-Text:
         Texto completo da exceção
 
-Exemplos de formato de arquivo::
+   ::
 
       SPDX-Exception-Identifier: GCC-exception-2.0
       SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
@@ -436,7 +436,7 @@ _`MODULE_LICENSE`
    de módulos do kernel e às ferramentas de espaço do usuário sobre o módulo ser
    software livre ou proprietário.
 
-   As strings de licença válidas para MODULE_LICENSE() são::
+   As strings de licença válidas para MODULE_LICENSE() são:
 
       ============================= =============================================
       "GPL"                         O módulo está licenciado sob a GPL versão 2.
-- 
2.47.3

[PATCH 08/11] docs/translations/pt_BR: process: 2.Process.rst: fix translation errors

[Daniel Pereira]

Fix errors against the English text:

- the merge window paragraph added content that is not in the original
  ("all code", "mandatorily", "frantic", bold text) and dropped
  "relatively", "sufficiently stable" and "for a new development cycle";
  its nested bold/italic markup also rendered with visible asterisks;
- "hopefully" was translated as "fortunately";
- "eventually" was translated with the false friend "eventualmente"
  three times;
- "a common place to go wrong" was translated as a cliché;
- "will not even compile" and "if it is to remain useful" had their
  meaning changed, and "should really" was weakened to "ideally";
- the sentence about asking Linus to pull was garbled;
- restore "(described below)" and "inline", and use the plural in the
  "Next trees" title.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../translations/pt_BR/process/2.Process.rst  | 46 ++++++++++---------
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/2.Process.rst b/Documentation/translations/pt_BR/process/2.Process.rst
index a0b6decfa..1e0e7dd6e 100644
--- a/Documentation/translations/pt_BR/process/2.Process.rst
+++ b/Documentation/translations/pt_BR/process/2.Process.rst
@@ -34,14 +34,14 @@ juntamente com suas datas, podem ser encontrados na `Wikipedia
        incrementado apenas se x for considerado grande o suficiente
        (por exemplo, o Linux 5.0 foi lançado após o Linux 4.20).
 
-O processo de integração (*merging*) de patches segue um fluxo simples a
-cada lançamento. No início de cada ciclo de desenvolvimento, abre-se a
-**"janela de integração" (*merge window*)**. Durante esse período, todo
-código considerado estável e aprovado pela comunidade é unificado ao
-kernel principal (*mainline*). A maior parte das novidades  e todas as
-grandes mudanças estruturais — entra obrigatoriamente nessa fase, em um
-ritmo frenético que chega a **1.000 patches (ou conjuntos de alterações)
-por dia**.
+O processo de integração (*merging*) de patches segue um fluxo relativamente
+simples a cada lançamento. No início de cada ciclo de desenvolvimento, abre-se
+a "janela de integração" (*merge window*). Durante esse período, o código
+considerado suficientemente estável (e aprovado pela comunidade de
+desenvolvimento) é integrado ao kernel principal (*mainline*). A maior parte
+das mudanças de um novo ciclo de desenvolvimento (e todas as grandes
+mudanças) entra nessa fase, em um ritmo que se aproxima de 1.000 mudanças
+("patches" ou "conjuntos de alterações") por dia.
 
 (Como observação secundária, vale destacar que as mudanças integradas durante
 a janela de integração não surgem do nada; elas foram coletadas, testadas e
@@ -104,7 +104,7 @@ projeto deste tamanho. Chega um ponto em que adiar o lançamento final apenas
 torna o problema pior; o volume de mudanças esperando pela próxima janela de
 integração crescerá ainda mais, criando ainda mais regressões no ciclo
 seguinte. Portanto, a maioria dos kernels é lançada com um pequeno número de
-regressões conhecidas, embora, felizmente, nenhuma delas seja grave.
+regressões conhecidas, embora, com sorte, nenhuma delas seja grave.
 
 Assim que um lançamento estável é feito, sua manutenção contínua é passada
 para a "equipe estável" (*stable team*), atualmente composta por Greg
@@ -178,7 +178,8 @@ As etapas pelas quais um patch passa são, geralmente:
    pronto para inclusão no mainline, ele deve ser aceito por um mantenedor de
    subsistema relevante — embora essa aceitação não seja uma garantia de que
    o patch chegará até o kernel principal. O patch aparecerá na árvore de
-   subsistema do mantenedor e nas árvores -next. Quando o processo funciona,
+   subsistema do mantenedor e nas árvores -next (descritas abaixo). Quando o
+   processo funciona,
    esta etapa leva a uma revisão mais ampla do patch e à descoberta de
    quaisquer problemas resultantes da integração deste patch com o trabalho
    que está sendo feito por outros.
@@ -193,7 +194,7 @@ As etapas pelas quais um patch passa são, geralmente:
    atual (garantindo que ele seja aplicado de forma limpa) e continuar
    enviando-o para revisão e integração.
 
- - Integração no mainline. Eventualmente, um
+ - Integração no mainline. Por fim, um
    patch bem-sucedido será integrado ao repositório principal (*mainline*)
    gerenciado por Linus Torvalds. Mais comentários e/ou problemas podem surgir
    neste momento; é importante que o desenvolvedor seja responsivo a eles e
@@ -209,7 +210,7 @@ As etapas pelas quais um patch passa são, geralmente:
    desenvolvimento. Integrar o código elimina parte do fardo de manutenção,
    já que outros corrigirão problemas causados por mudanças de API. No entanto,
    o desenvolvedor original deve continuar assumindo a responsabilidade pelo
-   código se ele quiser que este permaneça útil no longo prazo.
+   código para que ele permaneça útil no longo prazo.
 
 Um dos maiores erros cometidos por desenvolvedores do kernel (ou por seus
 empregadores) é tentar reduzir todo o processo a uma única etapa de
@@ -246,8 +247,9 @@ autoria e outros metadados. A qualquer momento, o mantenedor pode identificar
 quais patches em seu repositório não são encontrados no mainline.
 
 Quando a janela de integração se abre, os mantenedores de
-alto nível pedirão a Linus para realizar o pull de seus repositórios os patches
-que selecionaram para integração. Se Linus concordar, o fluxo de patches
+alto nível pedirão a Linus para realizar o "pull", a partir de seus
+repositórios, dos patches que selecionaram para integração. Se Linus
+concordar, o fluxo de patches
 subirá para o seu repositório, tornando-se parte do kernel principal. A
 quantidade de atenção que Linus dedica a patches específicos
 recebidos em uma operação de pull varia. Está claro que, às vezes, ele os
@@ -268,7 +270,7 @@ encontrar o mantenedor correto. Enviar patches diretamente para Linus
 normalmente não é o caminho certo a seguir.
 
 
-Árvore -next
+Árvores -next
 -------------
 
 A cadeia de árvores de subsistemas orienta o fluxo de patches para o kernel,
@@ -297,7 +299,7 @@ para a qual não existe uma árvore de subsistema designada. Como resultado, a
 -mm opera como uma espécie de árvore de subsistema de "último recurso"; se
 não houver outro caminho óbvio para um patch entrar no mainline, é provável
 que ele acabe na -mm. Patches diversos que se acumulam na
--mm eventualmente serão encaminhados para uma árvore de subsistema adequada
+-mm por fim serão encaminhados para uma árvore de subsistema adequada
 ou enviados diretamente para Linus. Em um ciclo de desenvolvimento típico,
 aproximadamente 5% a 10% do total de patches que entram no mainline chegam
 lá por meio da -mm.
@@ -308,7 +310,7 @@ em:
 	https://www.ozlabs.org/~akpm/mmotm/
 
 O uso da árvore MMOTM, no entanto, provavelmente será uma experiência
-frustrante; existe uma chance real de que ela sequer compile.
+frustrante; existe uma chance real de que ela nem sequer compile.
 
 A árvore primária para a integração de patches do próximo ciclo é a
 linux-next, mantida por Mark Brown. A árvore linux-next é, por design, um
@@ -321,7 +323,7 @@ quando são montadas; elas podem ser baixadas em:
 
 A linux-next tornou-se uma parte integrante do processo de desenvolvimento
 do kernel; todos os patches integrados durante uma determinada janela de
-integração devem, idealmente, ter encontrado seu caminho para a linux-next algum
+integração devem realmente ter encontrado seu caminho para a linux-next algum
 tempo antes da abertura da janela de integração.
 
 
@@ -349,7 +351,7 @@ O staging pode ser uma maneira relativamente fácil de colocar novos drivers
 no mainline onde, com sorte, eles chamarão a atenção de outros desenvolvedores
 e melhorarão rapidamente. No entanto, a entrada no staging não é o fim da
 história; o código no staging que não apresentar progresso regular será,
-eventualmente, removido. Os distribuidores também tendem a ser relativamente
+com o tempo, removido. Os distribuidores também tendem a ser relativamente
 relutantes em habilitar drivers do staging. Portanto, o staging é, na melhor
 das hipóteses, uma parada no caminho para se tornar um driver mainline adequado.
 
@@ -454,7 +456,7 @@ Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
   perguntas. Alguns desenvolvedores podem ficar impacientes com pessoas que
   claramente não fizeram sua lição de casa.
 
-- Use respostas intercaladas, o que torna sua resposta mais fácil
+- Use respostas intercaladas ("inline"), o que torna sua resposta mais fácil
   de ler. (ou seja, evite o "top-posting" — a prática de colocar sua resposta
   acima do texto citado ao qual você está respondendo). Para mais detalhes, veja
   :ref:`Documentation/process/submitting-patches.rst <pt_BR_interleaved_replies>`.
@@ -463,8 +465,8 @@ Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
   ponto de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores
   de todos os subsistemas.
 
-O último ponto, encontrar a lista de discussão correta, é um lugar comum
-onde os desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta
+O último ponto, encontrar a lista de discussão correta, é onde os
+desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta
 relacionada a redes na lista linux-kernel quase certamente receberá uma
 sugestão educada para perguntar na lista netdev em seu lugar, já que essa é a
 lista frequentada pela maioria dos desenvolvedores de redes. Existem outras
-- 
2.47.3

[PATCH 09/11] docs/translations/pt_BR: process: fix cross-references and list markup

[Daniel Pereira]

Several :ref: links in the pt_BR documents pointed to the English labels
even though the target document is translated. Point them to the pt_BR
labels, adding pt_BR_submitchecklist, pt_BR_email_clients and
pt_BR_stable_api_nonsense, which mirror the English labels.

While at it, fix markup that renders differently from the English
version: an unindented paragraph in howto.rst that broke the definition
list, a sub-item in email-clients.rst nested one level too deep, a book
title in 8.Conclusion.rst indented differently from its neighbours, and
a literal around the ABI document path in submit-checklist.rst that kept
it from being linked. Also update the Coccinelle URL in 4.Coding.rst,
which changed in the original.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../translations/pt_BR/process/4.Coding.rst   |  6 +++--
 .../translations/pt_BR/process/5.Posting.rst  | 22 +++++++++++--------
 .../pt_BR/process/8.Conclusion.rst            |  7 +++---
 .../pt_BR/process/email-clients.rst           | 12 +++++-----
 .../process/embargoed-hardware-issues.rst     |  2 +-
 .../translations/pt_BR/process/howto.rst      |  4 ++--
 .../pt_BR/process/stable-api-nonsense.rst     |  2 ++
 .../pt_BR/process/submit-checklist.rst        |  4 +++-
 8 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/4.Coding.rst b/Documentation/translations/pt_BR/process/4.Coding.rst
index 914a3d4c5..9c40f5468 100644
--- a/Documentation/translations/pt_BR/process/4.Coding.rst
+++ b/Documentation/translations/pt_BR/process/4.Coding.rst
@@ -24,7 +24,8 @@ Estilo de Codificação
 *********************
 
 O kernel há muito possui um estilo de codificação padrão, descrito em
-:ref:`Documentation/process/coding-style.rst <codingstyle>`. Por grande parte
+:ref:`Documentation/process/coding-style.rst
+<pt_BR_codingstyle>`. Por grande parte
 desse tempo, as políticas descritas naquele arquivo eram consideradas, no
 máximo, como recomendações. Como resultado, há uma quantidade substancial
 de código no kernel que não cumpre as diretrizes de estilo de codificação.
@@ -324,7 +325,8 @@ https://sparse.wiki.kernel.org/index.php/Main_Page se a sua distribuição não
 incluir como pacote); ele pode então ser executado no código adicionando "C=1"
 ao seu comando make.
 
-A ferramenta "Coccinelle" (http://coccinelle.lip6.fr/) é capaz de encontrar uma
+A ferramenta "Coccinelle"
+(https://coccinelle.gitlabpages.inria.fr/website) é capaz de encontrar uma
 ampla variedade de potenciais problemas de codificação; ela também pode propor
 correções para esses problemas. Uma quantidade considerável de "patches
 semânticos" para o kernel foi empacotada sob o diretório scripts/coccinelle;
diff --git a/Documentation/translations/pt_BR/process/5.Posting.rst b/Documentation/translations/pt_BR/process/5.Posting.rst
index 60e12c1ee..cace3051c 100644
--- a/Documentation/translations/pt_BR/process/5.Posting.rst
+++ b/Documentation/translations/pt_BR/process/5.Posting.rst
@@ -12,8 +12,8 @@ conjunto de convenções e procedimentos que são usados no envio de patches;
 segui-los tornará a vida muito mais fácil para todos os envolvidos. Este
 documento tentará cobrir essas expectativas em detalhes razoáveis; mais
 informações também podem ser encontradas nos arquivos
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
-e :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.
+:ref:`Documentation/process/submitting-patches.rst <pt_BR_submittingpatches>`
+e :ref:`Documentation/process/submit-checklist.rst <pt_BR_submitchecklist>`.
 
 
 Quando enviar
@@ -203,7 +203,8 @@ a alteração em um sistema de controle de versão. Ele será seguido por:
 
 Os marcadores (tags) já mencionados brevemente acima são usados para fornecer
 informações sobre como o patch surgiu. Eles são descritos em detalhes no
-documento :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`;
+documento :ref:`Documentation/process/submitting-patches.rst
+<pt_BR_submittingpatches>`;
 o que se segue aqui é um breve resumo.
 
 Um marcador é usado para se referir a commits anteriores que introduziram os
@@ -242,15 +243,17 @@ Os marcadores de uso comum são:
    tem o direito de enviar o patch para inclusão no kernel. É um acordo com o
    Developer's Certificate of Origin (Certificado de Origem do Desenvolvedor),
    cujo texto completo pode ser encontrado em
-   :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
+   :ref:`Documentation/process/submitting-patches.rst
+   <pt_BR_submittingpatches>`.
    Códigos sem um signoff adequado não podem ser mesclados (merged) no mainline.
 
  - Co-developed-by: afirma que o patch foi criado em coautoria por vários
    desenvolvedores; é usado para dar atribuição aos coautores (além do autor
    atribuído pelo marcador From:) quando várias pessoas trabalham em um único
-   patch. Cada Co-developed-by: deve ser imediatamente seguido por um
-   Signed-off-by: do coautor associado. Detalhes e exemplos podem ser encontrados
-   em :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
+   patch. Cada Co-developed-by: deve ser imediatamente seguido por
+   um Signed-off-by: do coautor associado. Detalhes e exemplos podem ser
+   encontrados em :ref:`Documentation/process/submitting-patches.rst
+   <pt_BR_submittingpatches>`.
 
  - Acked-by: indica o acordo de outro desenvolvedor (frequentemente um
    mantenedor do código relevante) de que o patch é apropriado para inclusão
@@ -261,7 +264,7 @@ Os marcadores de uso comum são:
 
  - Reviewed-by: o desenvolvedor nomeado revisou o patch para verificar sua
    correção; veja a declaração do revisor em
-   :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+   :ref:`Documentation/process/submitting-patches.rst <pt_BR_submittingpatches>`
    para mais detalhes.
 
  - Reported-by: nomeia um usuário que relatou o problema que é corrigido por este
@@ -302,7 +305,8 @@ você deve se preocupar:
    e, frequentemente, não serão examinados em detalhes. Se houver qualquer
    dúvida, envie o patch para você mesmo e certifique-se de que ele chegue intacto.
 
-   O documento :ref:`Documentation/process/email-clients.rst <email_clients>`
+   O documento :ref:`Documentation/process/email-clients.rst
+   <pt_BR_email_clients>`
    possui algumas dicas úteis sobre como fazer clientes de e-mail específicos
    funcionarem para o envio de patches.
 
diff --git a/Documentation/translations/pt_BR/process/8.Conclusion.rst b/Documentation/translations/pt_BR/process/8.Conclusion.rst
index 6691627b2..09d6b350d 100644
--- a/Documentation/translations/pt_BR/process/8.Conclusion.rst
+++ b/Documentation/translations/pt_BR/process/8.Conclusion.rst
@@ -8,8 +8,9 @@ Para mais informações
 Há inúmeras fontes de informação sobre o desenvolvimento do kernel Linux e
 tópicos relacionados. A primeira delas sempre será o diretório Documentation
 encontrado na distribuição do código-fonte do kernel. Comece com o arquivo de
-nível superior :ref:`process/howto.rst <process_howto>`; leia também
-:ref:`process/submitting-patches.rst <submittingpatches>`. Muitas APIs internas
+nível superior :ref:`process/howto.rst <pt_process_howto>`; leia também
+:ref:`process/submitting-patches.rst
+<pt_BR_submittingpatches>`. Muitas APIs internas
 do kernel são documentadas usando o mecanismo kerneldoc; "make htmldocs" ou
 "make pdfdocs" podem ser usados para gerar esses documentos em formato HTML ou
 PDF (embora a versão do TeX fornecida por algumas distribuições esbarre em
@@ -37,7 +38,7 @@ Há uma série de livros sobre o desenvolvimento do kernel:
 
 	Linux Kernel Development (Robert Love).
 
-    Understanding the Linux Kernel (Daniel Bovet and Marco Cesati).
+	Understanding the Linux Kernel (Daniel Bovet and Marco Cesati).
 
 Todos esses livros, no entanto, sofrem de um defeito comum: eles tendem a estar
 um pouco obsoletos quando chegam às prateleiras, e já estão nelas há algum
diff --git a/Documentation/translations/pt_BR/process/email-clients.rst b/Documentation/translations/pt_BR/process/email-clients.rst
index ed8c810d3..962d8d7a0 100644
--- a/Documentation/translations/pt_BR/process/email-clients.rst
+++ b/Documentation/translations/pt_BR/process/email-clients.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_email_clients:
+
 Informações sobre clientes de email para Linux
 ==============================================
 
@@ -321,14 +323,14 @@ Para colocar juízo no editor interno, faça o seguinte:
 
   - Defina ``mailnews.send_plaintext_flowed`` como ``false``
 
-    - Altere ``mailnews.wraplength`` de ``72`` para ``0`` **ou** instale a
-      extensão "Toggle Line Wrap"
+  - Altere ``mailnews.wraplength`` de ``72`` para ``0`` **ou** instale a
+    extensão "Toggle Line Wrap"
 
-      https://github.com/jan-kiszka/togglelinewrap
+    https://github.com/jan-kiszka/togglelinewrap
 
-      https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
+    https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
 
-      para controlar esse registro dinamicamente.
+    para controlar esse registro dinamicamente.
 
 - Não escreva mensagens em HTML! Vá até a janela principal
   :menuselection:`Menu Principal-->Configurações da Conta-->suaconta@servidor.algo-->Composição e Endereçamento`!
diff --git a/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst b/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
index ae1fda088..2d13b335b 100644
--- a/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
+++ b/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
@@ -29,7 +29,7 @@ A equipe lida apenas com o desenvolvimento de correções para problemas de
 segurança de hardware sob embargo. Relatos de bugs de segurança de software puro
 no kernel Linux não são tratados por esta equipe, e o autor do relato será
 orientado a contatar a equipe regular de segurança do kernel Linux
-(:ref:`Documentation/admin-guide/ <securitybugs>`) em vez disso.
+(:ref:`Documentation/admin-guide/ <pt_BR_securitybugs>`) em vez disso.
 
 A equipe pode ser contatada por e-mail em <hardware-security@kernel.org>. Esta
 é uma lista privada de oficiais de segurança que ajudarão você a coordenar uma
diff --git a/Documentation/translations/pt_BR/process/howto.rst b/Documentation/translations/pt_BR/process/howto.rst
index 54ea7fad8..518e62d37 100644
--- a/Documentation/translations/pt_BR/process/howto.rst
+++ b/Documentation/translations/pt_BR/process/howto.rst
@@ -124,7 +124,7 @@ que são de leitura obrigatória:
     estão sujeitos a um escrutínio de conteúdo e estilo), mas não segui-las
     quase sempre o impedirá.
 
-Outras excelentes descrições de como criar patches adequadamente são:
+    Outras excelentes descrições de como criar patches adequadamente são:
 
 	"O Patch Perfeito"
 		https://www.ozlabs.org/~akpm/stuff/tpp.txt
@@ -132,7 +132,7 @@ Outras excelentes descrições de como criar patches adequadamente são:
 	"Formato de Submissão de Patch do Kernel Linux"
 		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
 
-  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
+  :ref:`Documentation/translations/pt_BR/process/stable-api-nonsense.rst <pt_BR_stable_api_nonsense>`
     Este arquivo descreve a justificativa por trás da decisão consciente de
     não ter uma API estável dentro do kernel, incluindo pontos como:
 
diff --git a/Documentation/translations/pt_BR/process/stable-api-nonsense.rst b/Documentation/translations/pt_BR/process/stable-api-nonsense.rst
index c5d0e643e..4912048f4 100644
--- a/Documentation/translations/pt_BR/process/stable-api-nonsense.rst
+++ b/Documentation/translations/pt_BR/process/stable-api-nonsense.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_stable_api_nonsense:
+
 A interface de drivers do kernel Linux
 =======================================
 
diff --git a/Documentation/translations/pt_BR/process/submit-checklist.rst b/Documentation/translations/pt_BR/process/submit-checklist.rst
index 3e0ee38b9..d5706bfe2 100644
--- a/Documentation/translations/pt_BR/process/submit-checklist.rst
+++ b/Documentation/translations/pt_BR/process/submit-checklist.rst
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _pt_BR_submitchecklist:
+
 ==============================================================
 Lista de verificação para submissão de patches do kernel Linux
 ==============================================================
@@ -59,7 +61,7 @@ Forneça documentação
 
 5) Todas as novas interfaces com o espaço de usuário (userspace) devem ser
    documentadas em ``Documentation/ABI/``. Consulte
-   ``Documentation/admin-guide/abi.rst`` (ou ``Documentation/ABI/README``)
+   Documentation/admin-guide/abi.rst (ou ``Documentation/ABI/README``)
    para obter mais informações. Patches que alteram interfaces de espaço
    de usuário devem incluir em cópia (CC) linux-api@vger.kernel.org.
 
-- 
2.47.3

[PATCH 10/11] docs/translations/pt_BR: process: restore links, emphasis and headings

[Daniel Pereira]

Fix markup that differs from the English version:

- coding-style.rst: function names wrapped in literals were not turned
  into links as in the original, and a literal closed in the middle of
  a word ("typedef``s") rendered with visible backquotes;
- maintainer-kvm-x86.rst: "Timeline" was a section instead of a
  subsection;
- management-style.rst and backporting.rst: restore the emphasis
  dropped in five places.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../translations/pt_BR/process/backporting.rst     |  6 +++---
 .../translations/pt_BR/process/coding-style.rst    | 14 +++++++-------
 .../pt_BR/process/maintainer-kvm-x86.rst           |  2 +-
 .../pt_BR/process/management-style.rst             |  6 +++---
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/backporting.rst b/Documentation/translations/pt_BR/process/backporting.rst
index afcff7085..85128c1ee 100644
--- a/Documentation/translations/pt_BR/process/backporting.rst
+++ b/Documentation/translations/pt_BR/process/backporting.rst
@@ -93,7 +93,7 @@ O que fazer agora?
 
 Em geral, os conflitos aparecem quando o contexto do patch (ou seja, as linhas
 que estão sendo alteradas e/ou as linhas que cercam as alterações) não
-corresponde ao que está na árvore à qual você está tentando aplicar o patch.
+corresponde ao que está na árvore *à qual* você está tentando aplicar o patch.
 
 No caso de backports, o que provavelmente aconteceu foi que a ramificação
 (branch) a partir da qual você está fazendo o backport contém patches que não
@@ -137,8 +137,8 @@ Patches pré-requisitos
 ----------------------
 
 A maioria dos conflitos acontece porque a ramificação para a qual você está
-fazendo o backport não possui alguns patches em comparação com a ramificação a
-partir da qual você está fazendo o backport. No caso mais geral (como a
+fazendo o backport não possui alguns patches em comparação com a ramificação
+*a partir da qual* você está fazendo o backport. No caso mais geral (como a
 mesclagem de duas ramificações independentes), o desenvolvimento poderia ter
 ocorrido em qualquer uma das ramificações, ou as ramificações simplesmente
 divergiram -- talvez a sua ramificação mais antiga tenha recebido alguns outros
diff --git a/Documentation/translations/pt_BR/process/coding-style.rst b/Documentation/translations/pt_BR/process/coding-style.rst
index ac9bf0a71..af4124f57 100644
--- a/Documentation/translations/pt_BR/process/coding-style.rst
+++ b/Documentation/translations/pt_BR/process/coding-style.rst
@@ -384,7 +384,7 @@ Em contraste, se diz
 
 você consegue dizer o que ``a`` é.
 
-Muitas pessoas pensam que ``typedef``s ``ajudam na legibilidade``. Não é bem
+Muitas pessoas pensam que typedefs ``ajudam na legibilidade``. Não é bem
 assim. Eles são úteis apenas para:
 
  (a) objetos totalmente opacos (onde o ``typedef`` é usado ativamente para
@@ -926,7 +926,7 @@ que você deve usar para garantir que as mensagens sejam correspondidas ao
 dispositivo e driver corretos e sejam marcadas com o nível certo: ``dev_err()``,
 ``dev_warn()``, ``dev_info()`` e assim por diante. Para mensagens que não
 estão associadas a um device específico, <linux/printk.h> define
-``pr_notice()``, ``pr_info()``, ``pr_warn()``, ``pr_err()`` etc. Quando os
+pr_notice(), pr_info(), pr_warn(), pr_err() etc. Quando os
 drivers funcionam corretamente, eles ficam silenciosos, então prefira usar
 ``dev_dbg``/``pr_debug`` a menos que algo esteja errado.
 
@@ -934,7 +934,7 @@ Encontrar boas mensagens de depuração pode ser um desafio; e, uma vez que
 você tenha essas mensagens, elas podem ajudar bastante para solução de
 problemas remota. No entanto, a impressão de mensagens de depuração é tratada
 diferentemente da impressão de outras mensagens não de depuração. Enquanto as
-outras funções ``pr_XXX()`` imprimem incondicionalmente, ``pr_debug()`` não;
+outras funções ``pr_XXX()`` imprimem incondicionalmente, pr_debug() não;
 ela é compilada fora por padrão, a menos que ``DEBUG`` seja definido ou
 ``CONFIG_DYNAMIC_DEBUG`` esteja configurado. Isso também vale para
 ``dev_dbg()``, e uma convenção relacionada usa ``VERBOSE_DEBUG`` para adicionar
@@ -951,8 +951,8 @@ incondicionalmente, por exemplo, se ela já estiver dentro de uma seção
 --------------------
 
 O kernel fornece os seguintes alocadores de memória de uso geral:
-``kmalloc()``, ``kzalloc()``, ``kmalloc_objs()``, ``kzalloc_objs()``,
-``vmalloc()`` e ``vzalloc()``. Consulte a documentação da API para obter mais
+kmalloc(), kzalloc(), kmalloc_objs(), kzalloc_objs(),
+vmalloc() e vzalloc(). Consulte a documentação da API para obter mais
 informações sobre eles. :ref:`Documentation/core-api/memory-allocation.rst
 <memory_allocation>`
 
@@ -1008,7 +1008,7 @@ linhas de código. Uma exceção a essa regra são os casos em que um parâmetro
 conhecido como uma constante em tempo de compilação, e como resultado dessa
 constância você *sabe* que o compilador será capaz de otimizar grande parte da
 sua função em tempo de compilação. Para um bom exemplo desse caso posterior,
-veja a função inline ``kmalloc()``.
+veja a função inline kmalloc().
 
 Muitas pessoas argumentam que adicionar ``inline`` a funções ``static`` usadas
 apenas uma vez é sempre uma vantagem, porque não há custo de espaço. Embora
@@ -1037,7 +1037,7 @@ ajudar a evitar esses bugs, siga sempre esta convenção::
 
 Por exemplo, ``add work`` é um comando, e a função ``add_work()`` retorna 0
 para sucesso ou -EBUSY para falha. Da mesma forma, ``PCI device present`` é um
-predicado, e a função ``pci_dev_present()`` retorna 1 se encontrar um device
+predicado, e a função pci_dev_present() retorna 1 se encontrar um device
 correspondente ou 0 se não encontrar.
 
 Todas as funções ``EXPORT`` devem respeitar esta convenção, e assim também
diff --git a/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst b/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst
index ef133d32c..60712b9e9 100644
--- a/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst
@@ -69,7 +69,7 @@ A árvore do KVM x86 não possui sua própria janela de merge oficial, mas há u
 acima para correções destinadas ao lançamento atual).
 
 Cronograma
-----------
+~~~~~~~~~~
 As submissões são normalmente revisadas e aplicadas em ordem FIFO (primeiro a
 entrar, primeiro a sair), com alguma margem de manobra para o tamanho de uma
 série, patches que estão "cache hot", etc. Correções (fixes), especialmente para
diff --git a/Documentation/translations/pt_BR/process/management-style.rst b/Documentation/translations/pt_BR/process/management-style.rst
index 9d067e046..cd12ddca5 100644
--- a/Documentation/translations/pt_BR/process/management-style.rst
+++ b/Documentation/translations/pt_BR/process/management-style.rst
@@ -97,7 +97,7 @@ de antemão que você não tem a menor ideia, e dizendo às pessoas antes do fat
 que sua decisão é puramente preliminar, e pode ser a coisa errada. Você deve
 sempre reservar o direito de mudar de ideia, e fazer com que as pessoas estejam
 muito **cientes** disso. E é muito mais fácil admitir que você é estúpido quando
-você ainda não fez a coisa realmente estúpida.
+você **ainda** não fez a coisa realmente estúpida.
 
 Então, quando realmente se revela estúpido, as pessoas apenas reviram os olhos
 e dizem "Ops, não de novo".
@@ -149,7 +149,7 @@ um imbecil" de milhões de maneiras diferentes [#f2]_, às vezes sem nem percebe
 e quase sempre com uma convicção ardente de que você está certo.
 
 E quanto mais convencido você estiver de que está certo (e vamos encarar, você
-pode chamar praticamente qualquer pessoa de imbecil, e muitas vezes você **vai**
+pode chamar praticamente **qualquer pessoa** de imbecil, e muitas vezes você **vai**
 estar certo), mais difícil acaba sendo se desculpar depois.
 
 Para resolver esse problema, você realmente só tem duas opções:
@@ -230,7 +230,7 @@ desculpar, o segundo você realmente não terá a chance. Eles provavelmente nã
 estarão mais ouvindo, mesmo que você faça um bom trabalho de outra forma.
 
 Todos nós pensamos que somos melhores do que qualquer outra pessoa, o que significa
-que quando alguém posa de superior, isso realmente nos irrita. Você pode ser moral
+que quando alguém posa de superior, isso **realmente** nos irrita. Você pode ser moral
 e intelectualmente superior a todos ao seu redor, mas não tente tornar isso muito
 óbvio, a menos que você realmente **pretenda** irritar alguém [#f3]_.
 
-- 
2.47.3

[PATCH 11/11] docs/translations/pt_BR: process: fix kernel-docs and enforcement statement

[Daniel Pereira]

- kernel-docs.rst: "pre-order" was translated as "resale", a missing
  colon turned a field name into "Descrição Do site", and six book
  entries still had their "Title:" label in English;
- kernel-enforcement-statement.rst: add Laura Abbott, the first
  signatory, who was missing from the list.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../translations/pt_BR/process/kernel-docs.rst   | 16 ++++++++--------
 .../process/kernel-enforcement-statement.rst     |  1 +
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/kernel-docs.rst b/Documentation/translations/pt_BR/process/kernel-docs.rst
index 6235b1e7b..dd204430f 100644
--- a/Documentation/translations/pt_BR/process/kernel-docs.rst
+++ b/Documentation/translations/pt_BR/process/kernel-docs.rst
@@ -78,7 +78,7 @@ Documentação on-line
 Livros Publicados
 -----------------
 
-    * Title: **The Linux Memory Manager**
+    * Título: **The Linux Memory Manager**
 
       :Autor: Lorenzo Stoakes
       :Editora: No Starch Press
@@ -86,11 +86,11 @@ Livros Publicados
       :Páginas: 1300
       :ISBN: 978-1718504462
       :Notas: Gerenciamento de memória. Rascunho completo disponível como acesso
-        antecipado para ré-venda, lançamento completo agendado para o
+        antecipado para pré-venda, lançamento completo agendado para o
         outono de 2025. Veja https://nostarch.com/linux-memory-manager
         para mais informações.
 
-    * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition**
+    * Título: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition**
 
       :Autor: Kenneth Hess
       :Editora: O'Reilly Media
@@ -99,7 +99,7 @@ Livros Publicados
       :ISBN: 978-1098109035
       :Notas: Administração de sistemas
 
-    * Title: **Linux Kernel Debugging: Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules**
+    * Título: **Linux Kernel Debugging: Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules**
 
       :Autor: Kaiwan N Billimoria
       :Editora: Packt Publishing Ltd
@@ -108,7 +108,7 @@ Livros Publicados
       :ISBN: 978-1801075039
       :Notas: Livro sobre depuração (debugging)
 
-    * Title: **Linux Kernel Programming: A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization**
+    * Título: **Linux Kernel Programming: A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization**
 
       :Autor: Kaiwan N Billimoria
       :Editora: Packt Publishing Ltd
@@ -116,7 +116,7 @@ Livros Publicados
       :Páginas: 754
       :ISBN: 978-1789953435 (O ISBN da segunda edição é 978-1803232225)
 
-    * Title: **Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization: Create user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts**
+    * Título: **Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization: Create user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts**
 
       :Autor: Kaiwan N Billimoria
       :Editora: Packt Publishing Ltd
@@ -124,7 +124,7 @@ Livros Publicados
       :Páginas: 452
       :ISBN: 978-1801079518
 
-    * Title: **Linux System Programming: Talking Directly to the Kernel and C Library**
+    * Título: **Linux System Programming: Talking Directly to the Kernel and C Library**
 
       :Autor: Robert Love
       :Editora: O'Reilly Media
@@ -231,7 +231,7 @@ Rust
       :URL: https://rust-for-linux.com/
       :Data: versão contínua (rolling)
       :Palavras-chave: glossário, termos, linux-kernel, rust.
-      :Descrição Do site: "Rust for Linux é o projeto que adiciona suporte à
+      :Descrição: Do site: "Rust for Linux é o projeto que adiciona suporte à
         linguagem Rust ao kernel Linux. Este site pretende ser um hub de links,
         documentação e recursos relacionados ao projeto".
 
diff --git a/Documentation/translations/pt_BR/process/kernel-enforcement-statement.rst b/Documentation/translations/pt_BR/process/kernel-enforcement-statement.rst
index 3833c433c..c2e7dd2f2 100644
--- a/Documentation/translations/pt_BR/process/kernel-enforcement-statement.rst
+++ b/Documentation/translations/pt_BR/process/kernel-enforcement-statement.rst
@@ -53,6 +53,7 @@ projeto. Trabalhando juntos, seremos mais fortes.
 Exceto onde indicado abaixo, falamos apenas por nós mesmos, e não por qualquer
 empresa para a qual possamos trabalhar hoje, no passado ou no futuro.
 
+  - Laura Abbott
   - Bjorn Andersson (Linaro)
   - Andrea Arcangeli
   - Neil Armstrong
-- 
2.47.3