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

[Daniel Pereira <danielmaraboo@gmail.com>]

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