fix warning cards, tips and translation (#979)

website/docs/pt_BR/guide/app-profile.md

@@ -16,7 +16,7 @@ Os usuários com UID 0 são conhecidos como usuários root e os grupos com GID 0
 
 No caso do sistema Android, cada app é um usuário separado (excluindo cenários de UID compartilhados) com um UID exclusivo. Por exemplo, `0` representa o usuário root, `1000` representa `system`, `2000` representa o ADB shell e UIDs variando de `10.000` a `19.999` representam apps comuns.
 
-:::informações
+:::info INFORMAÇÕES
 Aqui, o UID mencionado não é o mesmo que o conceito de múltiplos usuários ou perfis de trabalho no sistema Android. Os perfis de trabalho são, na verdade, implementados particionando o intervalo UID. Por exemplo, 10000-19999 representa o usuário principal, enquanto 110000-119999 representa um perfil de trabalho. Cada app comum entre eles possui seu próprio UID exclusivo.
 :::
 
@@ -31,7 +31,7 @@ uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(ad
 
 Aqui, o UID é `2000` e o GID (ID do grupo primário) também é `2000`. Além disso, pertence a vários grupos suplementares, como `inet` (indicando a capacidade de criar soquetes `AF_INET` e `AF_INET6`) e `sdcard_rw` (indicando permissões de leitura/gravação para o cartão SD).
 
-O Perfil Raiz do KernelSU permite a personalização do UID, GID e grupos para o processo raiz após a execução de `su`. Por exemplo, o Perfil Raiz de um app raiz pode definir seu UID como `2000`, o que significa que ao usar `su`, as permissões reais do app estão no nível do ADB shell. O grupo `inet` pode ser removido, evitando que o comando `su` acesse a rede.
+O Perfil Raiz do KernelSU permite a personalização do UID, GID e grupos para o processo root após a execução de `su`. Por exemplo, o Perfil Raiz de um app root pode definir seu UID como `2000`, o que significa que ao usar `su`, as permissões reais do app estão no nível do ADB shell. O grupo `inet` pode ser removido, evitando que o comando `su` acesse a rede.
 
 :::tip OBSERVAÇÃO
 O Perfil do Aplicativo controla apenas as permissões do processo root após usar `su`; ele não controla as permissões do próprio app. Se um app solicitou permissão de acesso à rede, ele ainda poderá acessar a rede mesmo sem usar `su`. Remover o grupo `inet` de `su` apenas impede que `su` acesse a rede.
@@ -47,7 +47,7 @@ Para realizar verificações de permissão, as implementações tradicionais do
 
 A partir do Linux 2.2, o Linux divide os privilégios tradicionalmente associados ao superusuário em unidades distintas, conhecidas como capacidades, que podem ser habilitadas e desabilitadas de forma independente.
 
-Cada capacidade representa um ou mais privilégios. Por exemplo, `CAP_DAC_READ_SEARCH` representa a capacidade de ignorar verificações de permissão para leitura de arquivos, bem como permissões de leitura e execução de diretório. Se um usuário com um UID efetivo de `0` (usuário root) não tiver recursos `CAP_DAC_READ_SEARCH` ou superiores, isso significa que mesmo sendo root, ele não pode ler arquivos à vontade.
+Cada capacidade representa um ou mais privilégios. Por exemplo, `CAP_DAC_READ_SEARCH` representa a capacidade de ignorar verificações de permissão para leitura de arquivos, bem como permissões de leitura e execução de diretório. Se um usuário com um UID efetivo `0` (usuário root) não tiver recursos `CAP_DAC_READ_SEARCH` ou superiores, isso significa que mesmo sendo root, ele não pode ler arquivos à vontade.
 
 O Perfil Raiz do KernelSU permite a personalização das Capacidades do processo raiz após a execução de `su`, conseguindo assim conceder parcialmente "permissões de root". Ao contrário do UID e GID mencionados acima, certos apps root exigem um UID de `0` após usar `su`. Nesses casos, limitar as capacidades deste usuário root com UID `0` pode restringir suas operações permitidas.
 
@@ -57,7 +57,7 @@ Capacidade do Linux [documentação oficial](https://man7.org/linux/man-pages/ma
 
 ### SELinux
 
-SELinux é um poderoso mecanismo de Controle de Acesso Obrigatório (MAC). Ele opera com base no princípio de **negação padrão**: qualquer ação não explicitamente permitida é negada.
+SELinux é um poderoso mecanismo do Controle de Acesso Obrigatório (MAC). Ele opera com base no princípio de **negação padrão**: qualquer ação não explicitamente permitida é negada.
 
 O SELinux pode ser executado em dois modos globais:
 
@@ -65,16 +65,16 @@ O SELinux pode ser executado em dois modos globais:
 2. Modo de aplicação: Os eventos de negação são registrados e aplicados.
 
 :::warning AVISO
-Os sistemas Android modernos dependem fortemente do SELinux para garantir a segurança geral do sistema. É altamente recomendável não usar nenhum sistema personalizado executado em "modo permissivo", pois não oferece vantagens significativas em relação a um sistema completamente aberto..
+Os sistemas Android modernos dependem fortemente do SELinux para garantir a segurança geral do sistema. É altamente recomendável não usar nenhum sistema personalizado executado em "Modo permissivo", pois não oferece vantagens significativas em relação a um sistema completamente aberto.
 :::
 
-Explicar o conceito completo do SELinux é complexo e está além do escopo deste documento. Recomenda-se primeiro entender seu funcionamento através dos seguintes recursos:
+Explicar o conceito completo do SELinux é complexo e está além do objetivo deste documento. Recomenda-se primeiro entender seu funcionamento através dos seguintes recursos:
 
 1. [Wikipédia](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)
 2. [Red Hat: O que é SELinux?](https://www.redhat.com/en/topics/linux/what-is-selinux)
 3. [ArchLinux: SELinux](https://wiki.archlinux.org/title/SELinux)
 
-O Perfil Raiz do KernelSU permite a personalização do contexto SELinux do processo raiz após a execução de `su`. Regras específicas de controle de acesso podem ser definidas para este contexto para permitir um controle refinado sobre as permissões de root.
+O Perfil Raiz do KernelSU permite a personalização do contexto SELinux do processo root após a execução de `su`. Regras específicas de controle de acesso podem ser definidas para este contexto para permitir um controle refinado sobre as permissões de root.
 
 Em cenários típicos, quando um app executa `su`, ele alterna o processo para um domínio SELinux com **acesso irrestrito**, como `u:r:su:s0`. Através do Perfil Raiz, este domínio pode ser mudado para um domínio personalizado, como `u:r:app1:s0`, e uma série de regras podem ser definidas para este domínio:
 
@@ -85,13 +85,13 @@ typeattribute app1 mlstrustedsubject
 allow app1 * * *
 ```
 
-Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstração. Na prática, esta regra não deve ser utilizada extensivamente, pois não difere muito do modo permissivo.
+Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstração. Na prática, esta regra não deve ser utilizada extensivamente, pois não difere muito do Modo permissivo.
 
 ### Escalação
 
 Se a configuração do Perfil Raiz não estiver definida corretamente, poderá ocorrer um cenário de escalonamento: as restrições impostas pelo Perfil Raiz poderão falhar involuntariamente.
 
-Por exemplo, se você conceder permissão root a um usuário shell ADB (que é um caso comum) e, em seguida, conceder permissão root a um app normal, mas configurar seu perfil root com UID 2000 (que é o UID do usuário shell ADB) , o app pode obter acesso root completo executando o comando `su` duas vezes:
+Por exemplo, se você conceder permissão root a um usuário shell ADB (que é um caso comum) e, em seguida, conceder permissão root a um app normal, mas configurar seu perfil root com UID 2000 (que é o UID do usuário ADB shell), o app pode obter acesso root completo executando o comando `su` duas vezes:
 
 1. A primeira execução `su` está sujeita à aplicação do Perfil do Aplicativo e mudará para UID `2000` (adb shell) em vez de `0` (root).
 2. A segunda execução `su`, como o UID é `2000` e você concedeu acesso root ao UID `2000` (adb shell) na configuração, o app obterá privilégios de root completos.
@@ -99,20 +99,20 @@ Por exemplo, se você conceder permissão root a um usuário shell ADB (que é u
 :::warning OBSERVAÇÃO
 Este comportamento é totalmente esperado e não é um bug. Portanto, recomendamos o seguinte:
 
-Se você realmente precisa conceder permissões de root ao ADB (por exemplo, como desenvolvedor), não é aconselhável alterar o UID para `2000` ao configurar o Perfil Raiz. Usar `1000` (sistema) seria uma escolha melhor.
+Se você realmente precisa conceder permissões de root ao ADB (por exemplo, como desenvolvedor), não é aconselhável alterar o UID para `2000` ao configurar o Perfil Raiz. Usar `1000` (sistema) seria uma melhor escolha.
 :::
 
 ## Perfil não Raiz
 
 ### Desmontar Módulos
 
-O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem overlayfs. No entanto, alguns apps podem ser sensíveis a esse comportamento. Assim, podemos descarregar módulos montados nesses apps configurando a opção “desmontar módulo”.
+O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem de overlayfs. No entanto, alguns apps podem ser sensíveis a esse comportamento. Assim, podemos descarregar módulos montados nesses apps configurando a opção “desmontar módulo”.
 
 Além disso, a interface de configurações do gerenciador KernelSU fornece uma opção para "desmontar módulos por padrão". Por padrão, essa opção está **ativada**, o que significa que o KernelSU ou alguns módulos descarregarão módulos para este app, a menos que configurações adicionais sejam aplicadas. Se você não preferir esta configuração ou se ela afetar determinados apps, você terá as seguintes opções:
 
-1. Mantenha a opção "desmontar módulos por padrão" e desative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem carregamento de módulo (agindo como uma "lista de permissões").
-2. Desative a opção "desmontar módulos por padrão" e ative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem descarregamento de módulo (agindo como uma "lista negra").
+1. Mantenha a opção "desmontar módulos por padrão" e desative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem carregamento do módulo (agindo como uma "lista de permissões").
+2. Desative a opção "desmontar módulos por padrão" e ative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem descarregamento do módulo (agindo como uma "lista negra").
 
-:::INFORMAÇÕES
+:::info INFORMAÇÕES
 Em dispositivos que utilizam kernel versão 5.10 e superior, o kernel realiza o descarregamento dos módulos. No entanto, para dispositivos que executam versões de kernel abaixo de 5.10, essa opção é apenas uma opção de configuração e o próprio KernelSU não executa nenhuma ação. Alguns módulos, como Zygisksu, podem usar essa opção para determinar se o descarregamento do módulo é necessário.
 :::

website/docs/pt_BR/guide/difference-with-magisk.md

@@ -11,17 +11,17 @@ Embora existam muitas semelhanças entre os módulos KernelSU e os módulos Magi
 - service.sh: o tempo de execução e a semântica são exatamente os mesmos
 - system.prop: completamente o mesmo
 - sepolicy.rule: completamente o mesmo
-- BusyBox: os scripts são executados no BusyBox com o "modo autônomo" habilitado em ambos os casos
+- BusyBox: os scripts são executados no BusyBox com o "Modo Autônomo" ativado em ambos os casos
 
 ## Diferenças
 
-Antes de entender as diferenças, você precisa saber diferenciar se o seu módulo está rodando no KernelSU ou Magisk. Você pode usar a variável de ambiente `KSU` para diferenciá-la em todos os locais onde você pode executar scripts do módulo (`customize.sh`, `post-fs-data.sh`, `service.sh`). No KernelSU, esta variável de ambiente será definida como `true`.
+Antes de entender as diferenças, você precisa saber diferenciar se o seu módulo está rodando no KernelSU ou Magisk. Você pode usar a variável de ambiente `KSU` para diferenciá-la em todos os locais onde você pode executar os scripts do módulo (`customize.sh`, `post-fs-data.sh`, `service.sh`). No KernelSU, esta variável de ambiente será definida como `true`.
 
 Aqui estão algumas diferenças:
 
 - Os módulos KernelSU não podem ser instalados no modo Recovery.
 - Os módulos KernelSU não têm suporte integrado para Zygisk (mas você pode usar módulos Zygisk através do [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
-- O método para substituir ou excluir arquivos nos módulos KernelSU é completamente diferente do Magisk. KernelSU não suporta o método `.replace`. Em vez disso, você precisa criar um arquivo com o mesmo nome `mknod filename c 0 0` para excluir o arquivo correspondente.
+- O método para substituir ou excluir arquivos nos módulos KernelSU é completamente diferente do Magisk. O KernelSU não suporta o método `.replace`. Em vez disso, você precisa criar um arquivo com o mesmo nome `mknod filename c 0 0` para excluir o arquivo correspondente.
 - Os diretórios do BusyBox são diferentes. O BusyBox integrado no KernelSU está localizado em `/data/adb/ksu/bin/busybox`, enquanto no Magisk está em `/data/adb/magisk/busybox`. **Observe que este é um comportamento interno do KernelSU e pode mudar no futuro!**
 - KernelSU não suporta arquivos `.replace`; entretanto, KernelSU suporta as variáveis ​​`REMOVE` e `REPLACE` para remover ou substituir arquivos e pastas.
 - KernelSU adiciona o estágio `boot-completed` para executar alguns scripts na inicialização concluída.

website/docs/pt_BR/guide/faq.md

@@ -49,7 +49,7 @@ Achamos que não e esse não é o nosso objetivo. Magisk é bom o suficiente par
 
 ## Como integrar o KernelSU para o kernel antigo?
 
-Por favor, consulte [guia](how-to-integrate-for-non-gki)
+Por favor, consulte a guia [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki)
 
 ## Por que minha versão do Android é 13 e o kernel mostra “android12-5.10”?
 

website/docs/pt_BR/guide/hidden-features.md

@@ -0,0 +1,7 @@
+# Recursos ocultos
+
+## .ksurc
+
+Por padrão, `/system/bin/sh` carrega `/system/etc/mkshrc`.
+
+Você pode fazer su carregar um arquivo rc personalizado criando um arquivo `/data/adb/ksu/.ksurc`.

website/docs/pt_BR/guide/how-to-build.md

@@ -5,8 +5,8 @@ Primeiro, você deve ler a documentação oficial do Android para construção d
 1. [Construindo Kernels](https://source.android.com/docs/setup/build/building-kernels)
 2. [Versões de lançamento do GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
 
-::: aviso
-Esta página é para dispositivos GKI, se você usa um kernel antigo, consulte [como integrar o KernelSU para kernel antigo](how-to-integrate-for-non-gki)
+::: warning AVISO
+Esta página é para dispositivos GKI, se você usa um kernel antigo, consulte [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki)
 :::
 
 ## Construir Kernel
@@ -24,7 +24,7 @@ O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma con
 
 ### Construir
 
-Por favor, verifique os [documentos oficiais](https://source.android.com/docs/setup/build/building-kernels) first.
+Por favor, verifique os [documentos oficiais](https://source.android.com/docs/setup/build/building-kernels) primeiro.
 
 Por exemplo, precisamos construir a imagem do kernel aarch64:
 

website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md

@@ -37,7 +37,7 @@ Mas se você encontrar um loop de inicialização quando o KernelSU integrado, t
 
 :::tip COMO VERIFICAR SE O KPROBE ESTÁ QUEBRADO?
 
-comente `ksu_enable_sucompat()` e `ksu_enable_ksud()` em `KernelSU/kernel/ksu.c`, se o dispositivo inicializar normalmente, então o kprobe pode estar quebrado.
+Comente `ksu_enable_sucompat()` e `ksu_enable_ksud()` em `KernelSU/kernel/ksu.c`, se o dispositivo inicializar normalmente, então o kprobe pode estar quebrado.
 :::
 
 ## Modifique manualmente a fonte do kernel
@@ -221,7 +221,7 @@ index 2ff887661237..e758d7db7663 100644
 
 Para ativar o Modo de Segurança integrado do KernelSU, você também deve modificar `input_handle_event` em `drivers/input/input.c`:
 
-:::dica
+:::tip DICA
 É altamente recomendável ativar este recurso, é muito útil para evitar bootloops!
 :::
 

website/docs/pt_BR/guide/installation.md

@@ -2,20 +2,20 @@
 
 ## Verifique se o seu dispositivo é compatível
 
-Baixe o app gerenciador KernelSU em [Lançamentos do GitHub](https://github.com/tiann/KernelSU/releases) ou [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu), e instale-o no seu dispositivo:
+Baixe o app gerenciador KernelSU em [GitHub Releases](https://github.com/tiann/KernelSU/releases) ou [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu), e instale-o no seu dispositivo:
 
-- Se o app mostrar `Sem suporte`, significa que **Você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma imagem de inicialização para você atualizar.
+- Se o app mostrar `Sem suporte`, significa que **Você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma boot image para você atualizar.
 - Se o app mostrar `Não instalado`, então seus dispositivos são oficialmente suportados pelo KernelSU.
 
-:::informações
-Para dispositivos mostrando `Sem suporte`, aqui está um [Dispositivos com suporte não oficial](unofficially-support-devices.md), você mesmo pode compilar o kernel.
+::: info INFORMAÇÕES
+Para dispositivos mostrando `Sem suporte`, aqui está os [Dispositivos com suporte não oficial](unofficially-support-devices.md), você mesmo pode compilar o kernel.
 :::
 
 ## Backup padrão boot.img
 
 Antes de atualizar, você deve primeiro fazer backup do seu boot.img padrão. Se você encontrar algum bootloop, você sempre pode restaurar o sistema voltando para o boot de fábrica usando o fastboot.
 
-::: aviso
+::: warning AVISO
 Flashar pode causar perda de dados, certifique-se de executar esta etapa bem antes de prosseguir para a próxima! Você também pode fazer backup de todos os dados do seu telefone, se necessário.
 :::
 
@@ -39,7 +39,7 @@ w      .x         .y       -zzz           -k            -something
 
 `w.x-zzz-k` é a versão KMI. Por exemplo, se a versão do kernel de um dispositivo for `5.10.101-android12-9-g30979850fc20`, então seu KMI será `5.10-android12-9`; teoricamente, ele pode inicializar normalmente com outros kernels KMI.
 
-::: dica
+::: tip DICA
 Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso significa que `5.10.101-android12-9-g30979850fc20` tem o mesmo KMI que `5.10.137-android12-9-g30979850fc20`!
 :::
 
@@ -99,7 +99,7 @@ Você pode baixar o boot.img em [Lançamento do GitHub](https://github.com/tiann
 
 Onde `<format>` se refere ao formato de compactação do kernel do seu boot.img oficial, verifique o formato de compactação do kernel do seu boot.img original, você deve usar o formato correto, por exemplo. `lz4`, `gz`; se você usar um formato de compactação incorreto, poderá encontrar bootloop.
 
-::: informações
+::: info INFORMAÇÕES
 1. Você pode usar o magiskboot para obter o formato de compactação da sua inicialização original; é claro que você também pode perguntar a outras crianças mais experientes com o mesmo modelo do seu dispositivo. Além disso, o formato de compactação do kernel geralmente não muda; portanto, se você inicializar com êxito com um determinado formato de compactação, poderá tentar esse formato mais tarde.
 2. Os dispositivos Xiaomi geralmente usam `gz` ou **uncompressed**.
 3. Para dispositivos Pixel, siga as instruções abaixo.
@@ -113,7 +113,7 @@ Use `adb` para conectar seu dispositivo, execute `adb reboot bootloader` para en
 fastboot flash boot boot.img
 ```
 
-::: informações
+::: info INFORMAÇÕES
 Se o seu dispositivo suportar `fastboot boot`, você pode primeiro usar `fastboot boot boot.img` para tentar usar o boot.img para inicializar o sistema primeiro. Se algo inesperado acontecer, reinicie-o novamente para inicializar.
 :::
 
@@ -152,7 +152,7 @@ Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magisk
 
 ### Usando magiskboot
 
-1. Baixe o Magisk mais recente em [Página de lançamento](https://github.com/topjohnwu/Magisk/releases)
+1. Baixe o Magisk mais recente em [GitHub Releases](https://github.com/topjohnwu/Magisk/releases)
 2. Renomeie o Magisk-*.apk para Magisk-vesion.zip e descompacte-o.
 3. Envie `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so` para o seu dispositivo por adb: `adb push Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`
 4. Envie stock boot.img e Image em AnyKernel3 para o seu dispositivo.

website/docs/pt_BR/guide/module.md

@@ -17,7 +17,7 @@ Para aqueles que desejam usar este recurso “Modo Autônomo” fora do KernelSU
 
 Para garantir que todos os shells `sh` subsequentes executados também sejam executados em modo autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador KernelSU usam internamente), pois as variáveis ​​de ambiente são herdadas para os subprocesso.
 
-::: tip Diferença com Magisk
+::: tip DIFERENÇA COM MAGISK
 
 O BusyBox do KernelSU agora está usando o arquivo binário compilado diretamente do projeto Magisk. **Obrigado ao Magisk!** Portanto, você não precisa se preocupar com problemas de compatibilidade entre scripts BusyBox no Magisk e KernelSU porque eles são exatamente iguais!
 :::
@@ -78,7 +78,7 @@ Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura
 ├── .
 ```
 
-::: tip Diferença com Magisk
+::: tip DIFERENÇA COM MAGISK
 O KernelSU não possui suporte integrado para o Zygisk, portanto não há conteúdo relacionado ao Zygisk no módulo. No entanto, você pode usar [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) para suportar módulos Zygisk. Neste caso, o conteúdo do módulo Zygisk é idêntico ao suportado pelo Magisk.
 :::
 
@@ -108,8 +108,8 @@ Por favor, leia a seção [Scripts de inicialização](#boot-scripts) para enten
 
 Em todos os scripts do seu módulo, use `MODDIR=${0%/*}` para obter o caminho do diretório base do seu módulo; **NÃO** codifique o caminho do seu módulo em scripts.
 
-::: tip Diferença com Magisk
-Você pode usar a variável de ambiente `KSU` para determinar se um script está sendo executado no KernelSU ou Magisk. Se estiver executando em KernelSU, esse valor será definido como `true`.
+::: tip DIFERENÇA COM MAGISK
+Você pode usar a variável de ambiente `KSU` para determinar se um script está sendo executado no KernelSU ou Magisk. Se estiver executando no KernelSU, esse valor será definido como `true`.
 :::
 
 ### Diretório `system`
@@ -145,7 +145,7 @@ REPLACE="
 
 Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube` e `$MODPATH/system/app/Bloatware` e, em seguida, executará `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/YouTube` e `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/Bloatware`. Após o módulo entrar em vigor, `/system/app/YouTube` e `/system/app/Bloatware` serão substituídos por diretórios vazios.
 
-::: tip Diferença com Magisk
+::: tip DIFERENÇA COM MAGISK
 
 O mecanismo sem sistema do KernelSU é implementado através do overlayfs do kernel, enquanto o Magisk atualmente usa montagem mágica (montagem de ligação). Os dois métodos de implementação têm diferenças significativas, mas o objetivo final é o mesmo: modificar os arquivos /system sem modificar fisicamente a partição /system.
 :::
@@ -160,9 +160,9 @@ Este arquivo segue o mesmo formato de `build.prop`. Cada linha é composta por `
 
 Se o seu módulo exigir alguns patches adicionais de sepolicy, adicione essas regras a este arquivo. Cada linha neste arquivo será tratada como uma declaração de política.
 
-## Instalador de módulo
+## Instalador do módulo
 
-Um instalador de módulo KernelSU é um módulo KernelSU empacotado em um arquivo zip que pode ser atualizado no app gerenciador KernelSU. O instalador de módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo zip.
+Um instalador do módulo KernelSU é um módulo KernelSU empacotado em um arquivo zip que pode ser atualizado no app gerenciador KernelSU. O instalador do módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo zip.
 
 ```txt
 module.zip
@@ -174,8 +174,8 @@ module.zip
 │
 ```
 
-:::aviso
-O módulo KernelSU **NÃO** é compatível para instalação no recovery personalizado!
+::: warning AVISO
+O módulo KernelSU **NÃO** é compatível para instalação no Recovery personalizado!
 :::
 
 ### Costumização
@@ -200,7 +200,7 @@ O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "M
 - `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64`
 - `API` (int): o nível da API (versão do Android) do dispositivo (por exemplo, `23` para Android 6.0)
 
-::: aviso
+::: warning AVISO
 No KernelSU, `MAGISK_VER_CODE` é sempre `25200` e `MAGISK_VER` é sempre `v25.2`. Por favor, não use essas duas variáveis ​​para determinar se ele está sendo executado no KernelSU ou não.
 :::
 

website/docs/pt_BR/guide/unofficially-support-devices.md

@@ -1,10 +1,10 @@
 # Dispositivos com suporte não oficial
 
-::: aviso
+::: warning AVISO
 Nesta página, existem kernels para dispositivos não GKI que suportam o KernelSU mantidos por outros desenvolvedores.
 :::
 
-::: aviso
+::: warning AVISO
 Esta página é apenas para você encontrar o código-fonte correspondente ao seu dispositivo, **NÃO** significa que o código-fonte foi revisado pelos desenvolvedores do KernelSU. Você deve usá-lo por sua própria conta e risco.
 :::
 

website/docs/pt_BR/guide/what-is-kernelsu.md

@@ -14,7 +14,7 @@ Por favor, consulte: [Instalação](installation)
 
 ## Como construir
 
-[Como construir](how-to-build)
+[Como construir o KernelSU](how-to-build)
 
 ## Discussão