website: update translation (#1653)

docs/README_PT-BR.md

@@ -29,7 +29,7 @@ Atualmente, apenas `arm64-v8a` e `x86_64` são suportados.
 ## Uso
 
  - [Instalação](https://kernelsu.org/pt_BR/guide/installation.html)
- - [Como construir o KernelSU?](https://kernelsu.org/pt_BR/guide/how-to-build.html)
+ - [Como compilar o KernelSU?](https://kernelsu.org/pt_BR/guide/how-to-build.html)
  - [Site oficial](https://kernelsu.org/pt_BR/)
 
 ## Tradução

website/docs/.vitepress/locales/pt_BR.ts

@@ -22,7 +22,7 @@ export default defineConfig({
     ],
 
     footer: {
-        message: 'Lançado sob a Licença GPL3.',
+        message: 'Lançado sob a Licença GPL3',
         copyright: 'Copyright © Desenvolvedores do KernelSU atuais de 2022'
     },
 
@@ -47,7 +47,7 @@ function sidebarGuide() {
           { text: 'O que é KernelSU?', link: '/pt_BR/guide/what-is-kernelsu' },
           { text: 'Diferença com Magisk', link: '/pt_BR/guide/difference-with-magisk' },
           { text: 'Instalação', link: '/pt_BR/guide/installation' },
-          { text: 'Como construir?', link: '/pt_BR/guide/how-to-build' },
+          { text: 'Como compilar?', link: '/pt_BR/guide/how-to-build' },
           { text: 'Integração para dispositivos não GKI', link: '/pt_BR/guide/how-to-integrate-for-non-gki'},
           { text: 'Dispositivos com suporte não oficial', link: '/pt_BR/guide/unofficially-support-devices.md' },
           { text: 'Guias de módulo', link: '/pt_BR/guide/module.md' },

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

@@ -2,11 +2,11 @@
 
 O Perfil do Aplicativo é um mecanismo fornecido pelo KernelSU para personalizar a configuração de vários apps.
 
-Para apps com permissões de root (ou seja, capazes de usar `su`), o Perfil do Aplicativo também pode ser chamado de Perfil Root. Ele permite a customização das regras `uid`, `gid`, `groups`, `capabilities` e `SELinux` do comando `su`, restringindo assim os privilégios do usuário root. Por exemplo, ele pode conceder permissões de rede apenas para apps de firewall enquanto nega permissões de acesso a arquivos, ou pode conceder permissões de shell em vez de acesso root completo para apps congelados: **mantendo o poder confinado com o princípio do menor privilégio.**
+Para apps com privilégios root (ou seja, capazes de usar `su`), o Perfil do Aplicativo também pode ser chamado de Perfil root. Ele permite a customização das regras `uid`, `gid`, `grupos`, `capacidades` e `SELinux` do comando `su`, restringindo assim os privilégios do usuário root. Por exemplo, ele pode conceder permissões de rede apenas para apps de firewall enquanto nega permissões de acesso a arquivos, ou pode conceder permissões de shell em vez de acesso root completo para apps congelados: **mantendo o poder confinado com o princípio do menor privilégio.**
 
-Para apps comuns sem permissões de root, o Perfil do Aplicativo pode controlar o comportamento do kernel e do sistema de módulos em relação a esses apps. Por exemplo, pode determinar se as modificações resultantes dos módulos devem ser abordadas. O kernel e o sistema de módulos podem tomar decisões com base nesta configuração, como realizar operações semelhantes a "ocultar"
+Para apps comuns sem privilégios root, o Perfil do Aplicativo pode controlar o comportamento do kernel e do sistema de módulos em relação a esses apps. Por exemplo, pode determinar se as modificações resultantes dos módulos devem ser abordadas. O kernel e o sistema de módulos podem tomar decisões com base nesta configuração, como realizar operações semelhantes a "ocultar".
 
-## Perfil Root
+## Perfil root
 
 ### UID, GID e Grupos
 
@@ -31,13 +31,13 @@ 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 Root 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 Root de um app root pode definir seu UID como `2000`, 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 root 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 root de um app root pode definir seu UID como `2000`, 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`, e 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.
 :::
 
-O Perfil Root é aplicado no kernel e não depende do comportamento voluntário de apps root, ao contrário da troca de usuários ou grupos por meio de `su` A concessão da permissão `su` depende inteiramente do usuário e não do desenvolvedor.
+O Perfil root é aplicado no kernel e não depende do comportamento voluntário de apps root, ao contrário da troca de usuários ou grupos por meio de `su`. A concessão da permissão `su` depende inteiramente do usuário e não do desenvolvedor.
 
 ### Capacidades
 
@@ -49,10 +49,10 @@ A partir do Linux 2.2, o Linux divide os privilégios tradicionalmente associado
 
 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 Root do KernelSU permite a personalização das capacidades do processo root 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.
+O Perfil root do KernelSU permite a personalização das capacidades do processo root após a execução de `su`, conseguindo assim conceder parcialmente "privilégios 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.
 
 :::tip FORTE RECOMENDAÇÃO
-A [documentação oficial](https://man7.org/linux/man-pages/man7/capabilities.7.html) da Capacidade do Linux fornece explicações detalhadas das habilidades representadas por cada Capacidade. Se você pretende customizar Capacidades, é altamente recomendável que você leia este documento primeiro.
+A [documentação oficial](https://man7.org/linux/man-pages/man7/capabilities.7.html) da capacidade do Linux fornece explicações detalhadas das habilidades representadas por cada capacidade. Se você pretende customizar as capacidade, é altamente recomendável que você leia este documento primeiro.
 :::
 
 ### SELinux
@@ -74,9 +74,9 @@ Explicar o conceito completo do SELinux é complexo e está além do objetivo de
 2. [Red Hat: O que é SELinux?](https://www.redhat.com/pt-br/topics/linux/what-is-selinux)
 3. [ArchLinux: SELinux](https://wiki.archlinux.org/title/SELinux)
 
-O Perfil Root 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.
+O Perfil root 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 os privilégios 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 Root, 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:
+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 root, 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:
 
 ```sh
 type app1
@@ -89,26 +89,26 @@ Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstraç
 
 ### Escalação
 
-Se a configuração do Perfil Root não estiver definida corretamente, poderá ocorrer um cenário de escalação. As restrições impostas pelo Perfil Root poderão falhar involuntariamente.
+Se a configuração do Perfil root não estiver definida corretamente, poderá ocorrer um cenário de escalação. As restrições impostas pelo Perfil root poderão falhar involuntariamente.
 
-Por exemplo, se você conceder permissão root a um usuário ADB shell (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:
+Por exemplo, se você conceder permissão root a um usuário ADB shell (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égio de root completo.
+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 root completo.
 
 :::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 Root. Usar `1000` (system) seria uma melhor escolha.
+Se você realmente precisa conceder privilégios root ao ADB (por exemplo, como desenvolvedor), não é aconselhável alterar o UID para `2000` ao configurar o Perfil root. Usar `1000` (system) seria uma melhor escolha.
 :::
 
-## Perfil não Root
+## Perfil não root
 
 ### Desmontar módulos
 
 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ódulos".
 
-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:
+Além disso, a interface de configurações do gerenciador do 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 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").

website/docs/pt_BR/guide/faq.md

@@ -4,7 +4,7 @@
 
 Primeiro, seu dispositivo deve ser capaz de desbloquear o bootloader. Se não, então não há suporte.
 
-Em seguida, instale o app gerenciador do KernelSU em seu dispositivo e abra-o, se mostrar `Sem suporte` então seu dispositivo não pode ser suportado imediatamente, mas você pode construir a fonte do kernel e integrar o KernelSU para fazê-lo funcionar ou usar [Dispositivos com suporte não oficial](unofficially-support-devices).
+Em seguida, instale o gerenciador do KernelSU em seu dispositivo e abra-o, se mostrar `Sem suporte` então seu dispositivo não pode ser suportado imediatamente, mas você pode compilar a fonte do kernel e integrar o KernelSU para fazê-lo funcionar ou usar [Dispositivos com suporte não oficial](unofficially-support-devices).
 
 ## Para usar o KernelSU precisa desbloquear o bootloader?
 
@@ -12,7 +12,7 @@ Certamente, sim.
 
 ## KernelSU suporta módulos?
 
-Sim, verifique [Guias de módulo](module.md) por favor.
+Sim, verifique [Guias de módulo](module.md).
 
 ## KernelSU suporta Xposed?
 
@@ -24,7 +24,7 @@ KernelSU não tem suporte integrado ao Zygisk, mas você pode usar [ZygiskNext](
 
 ## KernelSU é compatível com o Magisk?
 
-O sistema de módulos do KernelSU está em conflito com a montagem mágica do Magisk, se houver algum módulo habilitado no KernelSU, então todo o Magisk não funcionaria.
+O sistema de módulos do KernelSU está em conflito com a montagem mágica do Magisk, se houver algum módulo ativado no KernelSU, então todo o Magisk não funcionaria.
 
 Mas se você usar apenas o `su` do KernelSU, então funcionará bem com o Magisk. KernelSU modifica o `kernel` e o Magisk modifica o `ramdisk`, eles podem trabalhar juntos.
 
@@ -41,11 +41,11 @@ Achamos que não e esse não é o nosso objetivo. O Magisk é bom o suficiente p
 É o kernel do dispositivo que afeta a compatibilidade do KernelSU e não tem nada a ver com a versão do Android. A única restrição é que os dispositivos lançados com Android 12 devem ser kernel 5.10+ (dispositivos GKI). Então:
 
 1. Os dispositivos lançados com Android 12 devem ser compatíveis.
-2. Dispositivos com kernel antigo (alguns dispositivos Android 12 também têm o kernel antigo) são compatíveis (você mesmo deve construir o kernel).
+2. Dispositivos com kernel antigo (alguns dispositivos com Android 12 também têm o kernel antigo) são compatíveis (você mesmo deve compilar o kernel).
 
 ## KernelSU suporta kernel antigo?
 
-É possível, o KernelSU é portado para o kernel 4.14 agora, para o kernel mais antigo, você precisa fazer o backport manualmente e PRs são sempre bem-vindas!
+É possível, o KernelSU é portado para o kernel 4.14 agora, para o kernel mais antigo, você precisa portar manualmente e PRs são sempre bem-vindas!
 
 ## Como integrar o KernelSU para o kernel antigo?
 
@@ -55,13 +55,13 @@ Por favor, consulte a guia [Como integrar o KernelSU para kernels não GKI](how-
 
 A versão do Kernel não tem nada a ver com a versão do Android, se você precisar fazer o flash do kernel, use sempre a versão do kernel, a versão do Android não é tão importante.
 
-## Eu sou GKI1.0, posso usar isso?
+## Eu sou GKI 1.0, posso usar isso?
 
-GKI1 é completamente diferente do GKI2, você deve compilar o kernel sozinho.
+GKI 1.0 é completamente diferente do GKI 2.0, você deve compilar o kernel sozinho.
 
 ## Como posso fazer `/system` RW?
 
-Não recomendamos que você modifique a partição do sistema diretamente. Você deve usar [Guias de módulo](module.md) para modificá-lo sem sistema. Se você insiste em fazer isso, verifique [magisk_overlayfs](https://github.com/HuskyDG/magic_overlayfs).
+Não recomendamos que você modifique a partição do sistema diretamente. Por favor, verifique [Guias de módulo](module.md) para modificá-lo sem sistema. Se você insiste em fazer isso, verifique [magisk_overlayfs](https://github.com/HuskyDG/magic_overlayfs).
 
 ## KernelSU pode modificar hosts? Como posso usar AdAway?
 
@@ -73,6 +73,6 @@ O arquivo `modules.img` de 1 TB é um arquivo de imagem de disco, **não se preo
 
 Se você estiver realmente insatisfeito com o tamanho deste arquivo, você pode usar o comando `resize2fs -M` para torná-lo seu tamanho real, mas o módulo pode não funcionar corretamente neste momento e não forneceremos nenhum suporte para isso.
 
-## Por que meu dispositivo mostra o tamanho do armazenamento errado?
+## Por que meu dispositivo mostra o tamanho de armazenamento errado?
 
-Certos dispositivos usam métodos não padrão para calcular o tamanho do armazenamento do dispositivo, potencialmente levando a cálculos de armazenamento imprecisos em apps e menus do sistema, especialmente ao lidar com arquivos esparsos de 1 TB. Embora esse problema pareça ser específico para os dispositivos Samsung, afetando apenas apps e serviços da Samsung, é essencial observar que a discrepância está principalmente no tamanho total do armazenamento, e o cálculo do espaço livre permanece preciso.
+Certos dispositivos usam métodos não padrão para calcular o tamanho de armazenamento do dispositivo, potencialmente levando a cálculos de armazenamento imprecisos em apps e menus do sistema, especialmente ao lidar com arquivos esparsos de 1 TB. Embora esse problema pareça ser específico para os dispositivos Samsung, afetando apenas apps e serviços da Samsung, é essencial observar que a discrepância está principalmente no tamanho total do armazenamento, e o cálculo do espaço livre permanece preciso.

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

@@ -1,6 +1,6 @@
-# Como construir o KernelSU?
+# Como compilar o KernelSU?
 
-Primeiro, você deve ler a documentação oficial do Android para construção do kernel:
+Primeiro, você deve ler a documentação oficial do Android para compilação do kernel:
 
 1. [Como criar kernels](https://source.android.com/docs/setup/build/building-kernels)
 2. [Builds de versão de imagem genérica do kernel (GKI)](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
@@ -9,7 +9,7 @@ Primeiro, você deve ler a documentação oficial do Android para construção d
 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 o kernel
+## Compilar o kernel
 
 ### Sincronize o código-fonte do kernel
 
@@ -20,13 +20,13 @@ repo init -m manifest.xml
 repo sync
 ```
 
-O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma construção exclusivamente, você pode usar o manifesto para fazer uma construção re-preduzível. Você deve baixar o arquivo de manifesto em [Builds de versão de imagem genérica do kernel (GKI)](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
+O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma compilação exclusivamente, você pode usar o manifesto para fazer uma compilação re-preduzível. Você deve baixar o arquivo de manifesto em [Builds de versão de imagem genérica do kernel (GKI)](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
 
 ### Construir
 
 Por favor, verifique [Como criar kernels](https://source.android.com/docs/setup/build/building-kernels) primeiro.
 
-Por exemplo, precisamos construir a imagem do kernel `aarch64`:
+Por exemplo, precisamos compilar a imagem do kernel `aarch64`:
 
 ```sh
 LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
@@ -34,23 +34,23 @@ LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
 
 Não se esqueça de adicionar o sinalizador `LTO=thin`, caso contrário a compilação poderá falhar se a memória do seu computador for inferior a 24 GB.
 
-A partir do Android 13, o kernel é construído pelo `bazel`:
+A partir do Android 13, o kernel é compilado pelo `bazel`:
 
 ```sh
 tools/bazel build --config=fast //common:kernel_aarch64_dist
 ```
 
 :::info INFORMAÇÕES
-Para alguns kernel do Android 14, para fazer o Wi-Fi/Bluetooth funcionar. Pode ser necessário remover todas as exportações protegidas por GKI:
+Para alguns kernel do Android 14, para fazer o Wi-Fi/Bluetooth funcionar. Pode ser necessário remover todas as exportações protegidas pelo GKI:
 
 ```sh
 rm common/android/abi_gki_protected_exports_*
 ```
 :::
 
-## Construir o kernel com KernelSU
+## Compilar o kernel com KernelSU
 
-Se você conseguir construir o kernel com sucesso, então construir o KernelSU é muito fácil. Selecione qualquer um executado no diretório raiz de origem do kernel:
+Se você conseguir compilar o kernel com sucesso, então compilar o KernelSU é muito fácil. Selecione qualquer um executado no diretório raiz de origem do kernel:
 
 ::: code-group
 

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

@@ -2,11 +2,11 @@
 
 O KernelSU pode ser integrado em kernels não GKI e foi portado para 4.14 e versões anteriores.
 
-Devido à fragmentação de kernels não GKI, não temos uma maneira uniforme de construí-lo, portanto não podemos fornecer boot.img não GKI. Mas você mesmo pode construir o kernel com o KernelSU integrado.
+Devido à fragmentação de kernels não GKI, não temos uma maneira uniforme de construí-lo, portanto não podemos fornecer o boot.img não GKI. Mas você mesmo pode compilar o kernel com o KernelSU integrado.
 
-Primeiro, você deve ser capaz de construir um kernel inicializável a partir do código-fonte do kernel. Se o kernel não for de código aberto, será difícil executar o KernelSU no seu dispositivo.
+Primeiro, você deve ser capaz de compilar um kernel inicializável a partir do código-fonte do kernel. Se o kernel não for de código aberto, será difícil executar o KernelSU no seu dispositivo.
 
-Se você puder construir um kernel inicializável, existem duas maneiras de integrar o KernelSU ao código-fonte do kernel:
+Se você puder compilar um kernel inicializável, existem duas maneiras de integrar o KernelSU ao código-fonte do kernel:
 
 1. Automaticamente com `kprobe`
 2. Manualmente
@@ -297,9 +297,9 @@ index 45306f9ef247..815091ebfca4 100755
  		add_input_randomness(type, code, value);
 ```
 
-### Como fazer backport de path_umount
+### Como portar path_umount
 
-Você pode fazer com que o recurso "Desmontar módulos" funcione em kernels pré-GKI fazendo backport manualmente do `path_umount` da versão 5.9. Você pode usar este patch como referência:
+Você pode fazer com que o recurso "Desmontar módulos" funcione em kernels pré-GKI portando manualmente `path_umount` da versão 5.9. Você pode usar este patch como referência:
 
 ```diff
 --- a/fs/namespace.c

website/docs/pt_BR/guide/installation.md

@@ -2,9 +2,9 @@
 
 ## Verifique se o seu dispositivo é compatível
 
-Baixe o app gerenciador do KernelSU em [GitHub Releases](https://github.com/tiann/KernelSU/releases), e instale-o no seu dispositivo:
+Baixe o gerenciador do KernelSU em [GitHub Releases](https://github.com/tiann/KernelSU/releases), 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 boot.img para você instalar.
+- Se o app mostrar `Sem suporte`, significa que **você deve compilar o kernel sozinho**. O KernelSU não fornecerá e nunca fornecerá um boot.img para você instalar.
 - Se o app mostrar `Não instalado`, então seu dispositivo é oficialmente suportado pelo KernelSU.
 
 ::: info INFORMAÇÕES
@@ -45,9 +45,9 @@ Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso signific
 
 ### Nível do patch de segurança {#security-patch-level}
 
-Dispositivos Android mais recentes podem ter mecanismos anti-rollback que não permitem flashar uma boot.img com um nível de patch de segurança antigo. Por exemplo, se o kernel do seu dispositivo for `5.10.101-android12-9-g30979850fc20`, o patch de segurança será `2023-11`, mesmo se você atualizar o kernel consistente com o KMI do kernel, se o nível do patch de segurança for anterior a `2023-11` (como `2023-06`), então isso pode causar bootloop.
+Dispositivos Android mais recentes podem ter mecanismos anti-rollback que não permitem flashar um boot.img com um nível do patch de segurança antigo. Por exemplo, se o kernel do seu dispositivo for `5.10.101-android12-9-g30979850fc20`, o patch de segurança será `2023-11`, mesmo se você atualizar o kernel consistente com o KMI do kernel, se o nível do patch de segurança for anterior a `2023-11` (como `2023-06`), então isso pode causar bootloop.
 
-Portanto, os kernels com os níveis de patch de segurança mais recentes são preferidos, mantendo a consistência do KMI.
+Portanto, os kernels com os níveis do patch de segurança mais recentes são preferidos, mantendo a consistência do KMI.
 
 ### Versão do kernel vs Versão do Android
 
@@ -57,7 +57,7 @@ Se você descobrir que a versão do seu kernel é `android12-5.10.101`, mas a ve
 
 ## Introdução
 
-Desde a versão `0.9.0`, KernelSU suporta dois modos de execução em dispositivos GKI:
+Desde a versão [0.9.0](https://github.com/tiann/KernelSU/releases/tag/v0.9.0), KernelSU suporta dois modos de execução em dispositivos GKI:
 
 1. `GKI`: Substitua o kernel original do dispositivo pelo **Generic Kernel Image** (GKI) fornecido pelo KernelSU.
 2. `LKM`: Carregue o **Loadable Kernel Module** (LKM) no kernel do dispositivo sem substituir o kernel original.
@@ -76,8 +76,8 @@ No modo GKI, o kernel original do dispositivo será substituído pela imagem gen
 No modo LKM, o kernel original do dispositivo não será substituído, mas o módulo do kernel carregável será carregado no kernel do dispositivo. As vantagens do modo LKM são:
 
 1. Não substituirá o kernel original do dispositivo. Se você tiver os requisitos especiais para o kernel original do dispositivo ou quiser usar o KernelSU enquanto usa um kernel de terceiros, poderá usar o modo LKM.
-2. É mais conveniente atualizar e OTA. Ao atualizar o KernelSU, você pode instalá-lo diretamente no gerenciador sem atualizar manualmente. Após o sistema OTA, você pode instalá-lo diretamente no segundo slot sem flashar manualmente.
+2. É mais conveniente atualizar o OTA. Ao atualizar o KernelSU, você pode instalá-lo diretamente no gerenciador sem atualizar manualmente. Após o sistema OTA, você pode instalá-lo diretamente no segundo slot sem flashar manualmente.
-3. Adequado para alguns cenários especiais, por exemplo, o LKM também pode ser carregado com permissões root temporárias. Como não é necessário substituir a partição boot, ele não acionará o AVB e não causará o bloqueio do dispositivo.
+3. Adequado para alguns cenários especiais, por exemplo, o LKM também pode ser carregado com privilégios root temporários. Como não é necessário substituir a partição boot, ele não acionará o AVB e não causará o bloqueio do dispositivo.
 4. O LKM pode ser desinstalado temporariamente. Se você deseja cancelar temporariamente o root, você pode desinstalar o LKM, este processo não requer o flash de partições, nem mesmo a reinicialização do dispositivo. Se quiser fazer root novamente, basta reiniciar o dispositivo.
 
 :::tip COEXISTÊNCIA DE DOIS MODOS
@@ -104,7 +104,7 @@ Ao contrário do modo GKI, o modo LKM modificará o `ramdisk`, portanto, em disp
 
 Abra o gerenciador, clique no ícone de instalação no canto superior direito e diversas opções aparecerão:
 
-1. Selecione e corrija um arquivo. Se o seu telefone não tiver permissões root, você pode escolher esta opção e, em seguida, selecionar seu firmware oficial, e o gerenciador irá corrigi-lo automaticamente. Você só precisa flashar este arquivo corrigido para obter permissões de root permanentemente.
+1. Selecione e corrija um arquivo. Se o seu telefone não tiver privilégios root, você pode escolher esta opção e, em seguida, selecionar seu firmware oficial, e o gerenciador irá corrigi-lo automaticamente. Você só precisa flashar este arquivo corrigido para obter privilégios root permanentemente.
 2. Instale diretamente. Se o seu telefone já estiver rooteado, você pode escolher esta opção, o gerenciador obterá automaticamente as informações do seu dispositivo e, em seguida, corrigirá o firmware oficial e irá fazer o flash automaticamente. Você pode considerar usar `fastboot boot` e o kernel GKI do KernelSU para obter root temporário e instalar o gerenciador, e então usar esta opção. Esta também é a principal forma de atualizar o KernelSU.
 3. Instale em outra partição. Se o seu dispositivo suportar partição A/B, você pode escolher esta opção, o gerenciador irá corrigir automaticamente o firmware oficial e, em seguida, instalá-lo em outra partição. Este método é adequado para dispositivos após o OTA, você pode instalá-lo diretamente em outra partição após o OTA e, em seguida, reiniciar o dispositivo.
 
@@ -150,12 +150,12 @@ ksud boot-patch -b <boot.img> --kmi android13-5.10
 
 Existem vários métodos de instalação para o modo GKI, cada um adequado para um cenário diferente, portanto escolha conforme necessário.
 
-1. Instalar com fastboot usando o boot.img fornecido por KernelSU
+1. Instalar com fastboot usando o boot.img fornecido pelo KernelSU
-2. Instalar com um app kernel flash, como KernelFlasher
+2. Instalar com um app kernel flash, como o Kernel Flasher
-3. Repare o boot.img manualmente e instale-o
+3. Corrigir boot.img manualmente e instala-lo
 4. Instalar com Recovery personalizado (por exemplo, TWRP)
 
-## Instalar com o boot.img fornecido por KernelSU
+## Instalar com o boot.img fornecido pelo KernelSU
 
 Se o `boot.img` do seu dispositivo usa um formato de compactação comumente usado, você pode usar as imagens GKI fornecidas pelo KernelSU para atualizá-lo diretamente. Não requer TWRP ou autocorreção da imagem.
 
@@ -173,7 +173,7 @@ Normalmente, existem três arquivos de inicialização em formatos diferentes no
 3. Para dispositivos Pixel, siga as instruções abaixo:
 :::
 
-### Flash boot.img para o dispositivo
+### Flash o boot.img para o dispositivo
 
 Use o `adb` para conectar seu dispositivo, execute `adb reboot bootloader` para entrar no modo fastboot e use este comando para flashar o KernelSU:
 
@@ -197,23 +197,23 @@ fastboot reboot
 
 Etapa:
 
-1. Baixe o zip AnyKernel3. Se você não sabe qual arquivo baixar, leia atentamente a descrição do [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento.
+1. Baixe o ZIP AnyKernel3. Se você não sabe qual arquivo baixar, leia atentamente a descrição do [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento.
 2. Abra o app Kernel Flasher (conceda as permissões de root necessárias) e use o ZIP AnyKernel3 fornecido para fazer o flash.
 
-Dessa forma, é necessário que o app Kernel Flasher tenha permissões root. Você pode usar os seguintes métodos para conseguir isso:
+Dessa forma, é necessário que o app Kernel Flasher tenha privilégios root. Você pode usar os seguintes métodos para conseguir isso:
 
 1. Seu dispositivo está rooteado. Por exemplo, você instalou o KernelSU e deseja atualizar para a versão mais recente ou fez o root por meio de outros métodos (como Magisk).
-2. Se o seu telefone não estiver rooteado, mas o telefone suportar o método de inicialização temporária como `fastboot boot boot.img`, você pode usar a imagem GKI fornecida pelo KernelSU para inicializar temporariamente o seu dispositivo, obter permissões de root temporária e, em seguida, usar o Kernel Flasher para obter privilégios de root permanente.
+2. Se o seu telefone não estiver rooteado, mas o telefone suportar o método de inicialização temporária como `fastboot boot boot.img`, você pode usar a imagem GKI fornecida pelo KernelSU para inicializar temporariamente o seu dispositivo, obter privilégios root temporário e, em seguida, usar o Kernel Flasher para obter privilégios root permanente.
 
 1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
 2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
 3. [Ex Kernel Manager](https://play.google.com/store/apps/details?id=flar2.exkernelmanager)
 
-PS. Este método é mais conveniente ao atualizar o KernelSU e pode ser feito sem um computador (faça um backup primeiro).
+Observação: Este método é mais conveniente ao atualizar o KernelSU e pode ser feito sem um computador (faça um backup primeiro).
 
-## Corrigir boot.img manualmente{#patch-boot-image}
+## Corrigir boot.img manualmente {#patch-boot-image}
 
-Para alguns dispositivos, o formato boot.img não é tão comum como `lz4`, `gz` e `uncompressed`. O mais típico é o Pixel, seu formato boot.img é `lz4_legacy` compactado, ramdisk pode ser `gz` também pode ser compactado `lz4_legacy`. Neste momento, se você flashar diretamente o boot.img fornecido pelo KernelSU, o telefone pode não conseguir inicializar. Neste momento, você pode corrigir manualmente o boot.img para conseguir isso.
+Para alguns dispositivos, o formato boot.img não é tão comum como `lz4`, `gz` e `uncompressed`. O mais típico é o Pixel, seu formato boot.img é `lz4_legacy` compactado, ramdisk pode ser `gz` e também pode ser compactado `lz4_legacy`. Neste momento, se você flashar diretamente o boot.img fornecido pelo KernelSU, o telefone pode não conseguir inicializar. Neste momento, você pode corrigir manualmente o boot.img para conseguir isso.
 
 É sempre recomendado usar `magiskboot` para corrigir imagens, existem duas maneiras:
 
@@ -228,7 +228,7 @@ Android-Image-Kitchen não é recomendado agora, porque ele não lida corretamen
 
 ### Preparação
 
-1. Obtenha o boot.img padrão do telefone. Você pode obtê-lo com os fabricantes do seu dispositivo Talvez você precise do [payload-dumper-go](https://github.com/ssut/payload-dumper-go).
+1. Obtenha o boot.img padrão do telefone. Você pode obtê-lo com os fabricantes do seu dispositivo. Talvez você precise do [payload-dumper-go](https://github.com/ssut/payload-dumper-go).
 2. Baixe o arquivo ZIP AnyKernel3 fornecido pelo KernelSU que corresponde à versão KMI do seu dispositivo. Você pode consultar [Instalar com Recovery personalizado](#install-with-custom-recovery).
 3. Descompacte o pacote AnyKernel3 e obtenha o arquivo `Image`, que é o arquivo do kernel do KernelSU.
 
@@ -246,7 +246,7 @@ Android-Image-Kitchen não é recomendado agora, porque ele não lida corretamen
 ### Usando o magiskboot no PC Windows/macOS/Linux {#using-magiskboot-on-PC}
 
 1. Baixe o `magiskboot` adequado para o seu sistema operacional em [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci).
-2. Prepare o boot.img padrão e Image em seu PC.
+2. Prepare o `boot.img` padrão e `Image` em seu PC.
 3. `chmod +x magiskboot`
 4. Entre no diretório apropriado, execute `./magiskboot unpack boot.img` para descompactar `boot.img`. Você obterá um arquivo `kernel`, este é o seu kernel padrão.
 5. Substitua `kernel` por `Image`: `mv -f Image kernel`.
@@ -266,13 +266,13 @@ Etapa:
 2. Reinicie o telefone no TWRP.
 3. Use o ADB para colocar AnyKernel3-*.zip no telefone em /sdcard e escolha instalá-lo na interface do TWRP, ou você pode diretamente `adb sideload AnyKernel-*.zip` para instalar.
 
-PS. Este método é adequado para qualquer instalação (não limitado à instalação inicial ou atualizações subsequentes), desde que você use o TWRP.
+Observação: Este método é adequado para qualquer instalação (não limitado à instalação inicial ou atualizações subsequentes), desde que você use o TWRP.
 
 ## Outros métodos
 
 Na verdade, todos esses métodos de instalação têm apenas uma ideia principal, que é **substituir o kernel original pelo fornecido pelo KernelSU**, desde que isso possa ser alcançado, ele pode ser instalado. Por exemplo, a seguir estão outros métodos possíveis.
 
-1. Primeiro instale o Magisk, obtenha privilégios de root através do Magisk e então use o kernel flasher para fazer o flash no zip AnyKernel do KernelSU.
+1. Primeiro instale o Magisk, obtenha privilégios root através do Magisk e então use o Kernel Flasher para fazer o flash no zip AnyKernel do KernelSU.
 2. Use algum kit de ferramentas de flash em PCs para flashar no kernel fornecido pelo KernelSU.
 
 Mas se não funcionar, por favor, tente o método `magiskboot`.

website/docs/pt_BR/guide/module-webui.md

@@ -24,7 +24,7 @@ Se sua página contém CSS e JavaScript, você também precisa colocá-la neste
 
 ## API JavaScript
 
-Se for apenas uma página de exibição, não será diferente de uma página da web normal. Mais importante ainda, KernelSU fornece uma série de APIs de sistema que permitem implementar as funções exclusivas do módulo.
+Se for apenas uma página de exibição, não será diferente de uma página web normal. Mais importante ainda, KernelSU fornece uma série de APIs de sistema que permitem implementar as funções exclusivas do módulo.
 
 KernelSU fornece uma biblioteca JavaScript e publica-a no [npm](https://www.npmjs.com/package/kernelsu), que você pode usar no código JavaScript de suas páginas da web.
 
@@ -36,7 +36,7 @@ import { exec } from 'kernelsu';
 const { errno, stdout } = exec("getprop ro.product.model");
 ```
 
-Para outro exemplo, você pode fazer com que a página da web seja exibida em tela inteira ou exibir um dica.
+Para outro exemplo, você pode fazer com que a página web seja exibida em tela inteira ou exibir um dica.
 
 [Documentação da API](https://www.npmjs.com/package/kernelsu)
 
@@ -45,4 +45,4 @@ Se você achar que a API existente não atende às suas necessidades ou é incon
 ## Algumas dicas
 
 1. Você pode usar `localStorage` normalmente para armazenar alguns dados, mas eles serão perdidos após a desinstalação do app gerenciador. Se precisar salvar persistentemente, você mesmo pode gravar os dados em algum diretório.
-2. Para páginas simples, recomendo que você use [parceljs](https://parceljs.org/) para empacotamento. Não requer configuração do zero e é muito conveniente de usar. Porém, se você é um mestre front-end ou tem suas próprias preferências, basta escolher o que você gosta!
+2. Para páginas simples, recomendo que você use [parceljs](https://parceljs.org/) para o empacotamento. Não requer configuração do zero e é muito conveniente de usar. Porém, se você é um mestre do front-end ou tem suas próprias preferências, basta escolher o que você gosta!

website/docs/pt_BR/guide/module.md

@@ -2,7 +2,7 @@
 
 O KernelSU fornece um mecanismo de módulo que consegue modificar o diretório do sistema enquanto mantém a integridade da partição do sistema. Este mecanismo é conhecido como "sem sistema".
 
-O mecanismo de módulo do KernelSU é quase o mesmo do Magisk. Se você está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos KernelSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler [Diferença com Magisk](difference-with-magisk.md).
+O mecanismo de módulos do KernelSU é quase o mesmo do Magisk. Se você está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos KernelSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler [Diferença com Magisk](difference-with-magisk.md).
 
 ## WebUI
 
@@ -10,13 +10,13 @@ Os módulos do KernelSU suportam a exibição de interfaces e a interação com
 
 ## BusyBox
 
-O KernelSU vem com um recurso binário BusyBox completo (incluindo suporte completo ao SELinux). O executável está localizado em `/data/adb/ksu/bin/busybox`. O BusyBox do KernelSU suporta o "ASH Standalone Shell Mode" alternável em tempo de execução. O que este Modo Autônomo significa é que ao executar no shell `ash` do BusyBox, cada comando usará diretamente o miniaplicativo dentro do BusyBox, independentemente do que estiver definido como `PATH`. Por exemplo, comandos como `ls`, `rm`, `chmod` **NÃO** usarão o que está em `PATH` (no caso do Android por padrão será `/system/bin/ls`, `/system/bin/rm` e `/system/bin/chmod` respectivamente), mas em vez disso chamará diretamente os miniaplicativos internos do BusyBox. Isso garante que os scripts sempre sejam executados em um ambiente previsível e sempre tenham o conjunto completo de comandos, independentemente da versão do Android em que estão sendo executados. Para forçar um comando a **NÃO** usar o BusyBox, você deve chamar o executável com caminhos completos.
+O KernelSU vem com um recurso binário BusyBox completo (incluindo suporte completo ao SELinux). O executável está localizado em `/data/adb/ksu/bin/busybox`. O BusyBox do KernelSU suporta "ASH Standalone Shell Mode" alternável em tempo de execução. O que este Modo Autônomo significa é que ao executar no shell `ash` do BusyBox, cada comando usará diretamente o miniaplicativo dentro do BusyBox, independentemente do que estiver definido em `PATH`. Por exemplo, comandos como `ls`, `rm`, `chmod` **NÃO** usarão o que está em `PATH` (no caso do Android, por padrão será `/system/bin/ls`, `/system/bin/rm` e `/system/bin/chmod` respectivamente), mas em vez disso chamará diretamente os miniaplicativos internos do BusyBox. Isso garante que os scripts sempre sejam executados em um ambiente previsível e sempre tenham o conjunto completo de comandos, independentemente da versão do Android em que estão sendo executados. Para forçar um comando a **NÃO** usar o BusyBox, você deve chamar o executável com caminhos completos.
 
 Cada script shell executado no contexto do KernelSU será executado no shell `ash` do BusyBox com o Modo Autônomo ativado. Para o que é relevante para desenvolvedores terceirizados, isso inclui todos os scripts de inicialização e scripts de instalação de módulos.
 
-Para aqueles que desejam usar o recurso “Modo Autônomo” fora do KernelSU, existem 2 maneiras de ativá-los:
+Para aqueles que desejam usar o recurso Modo Autônomo fora do KernelSU, existem 2 maneiras de ativá-los:
 
-1. Defina a variável de ambiente `ASH_STANDALONE` como `1`.<br>Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
+1. Definir a variável de ambiente `ASH_STANDALONE` como `1`.<br>Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
 2. Alternar com opções de linha de comando:<br>`/data/adb/ksu/bin/busybox sh -o standalone <script>`
 
 Para garantir que todos os shells `sh` subsequentes executados também sejam executados no Modo Autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador do KernelSU usam internamente), pois as variáveis ​​de ambiente são herdadas para os subprocesso.
@@ -50,19 +50,19 @@ Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura
 │   │
 │   │      *** Sinalizadores de status ***
 │   │
-│   ├── skip_mount          <--- Se existir, o KernelSU NÃO montará sua pasta de sistema
+│   ├── skip_mount          <--- Se existir, o KernelSU não montará sua pasta de sistema
-│   ├── disable             <--- Se existir, o módulo será desabilitado
+│   ├── disable             <--- Se existir, o módulo será desativado
 │   ├── remove              <--- Se existir, o módulo será removido na próxima reinicialização
 │   │
 │   │      *** Arquivos opcionais ***
 │   │
 │   ├── post-fs-data.sh     <--- Este script será executado em post-fs-data
 │   ├── post-mount.sh       <--- Este script será executado em post-mount
-│   ├── service.sh          <--- Este script será executado no late_start service
+│   ├── service.sh          <--- Este script será executado no serviço late_start
 │   ├── boot-completed.sh   <--- Este script será executado na inicialização concluída
 |   ├── uninstall.sh        <--- Este script será executado quando o KernelSU remover seu módulo
 │   ├── system.prop         <--- As propriedades neste arquivo serão carregadas como propriedades do sistema por resetprop
-│   ├── sepolicy.rule       <--- Regras adicionais de sepolicy personalizadas
+│   ├── sepolicy.rule       <--- Regras adicionais do sepolicy personalizadas
 │   │
 │   │      *** Gerado automaticamente, NÃO CRIE OU MODIFIQUE MANUALMENTE ***
 │   │
@@ -102,7 +102,7 @@ description=<string>
 - `id` deve corresponder a esta expressão regular: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
   Exemplo: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
   Este é o **identificador exclusivo** do seu módulo. Você não deve alterá-lo depois de publicado.
-- `versionCode` deve ser um **número inteiro**. Isso é usado para comparar versões
+- `versionCode` deve ser um **número inteiro**. Isso é usado para comparar versões.
 - Outros que não foram mencionados acima podem ser qualquer string de **linha única**.
 - Certifique-se de usar o tipo de quebra de linha `UNIX (LF)` e não o `Windows (CR+LF)` ou `Macintosh (CR)`.
 
@@ -110,7 +110,7 @@ description=<string>
 
 Por favor, leia a seção [Scripts de inicialização](#scripts-de-inicializacao) para entender a diferença entre `post-fs-data.sh` e `service.sh`. Para a maioria dos desenvolvedores de módulos, `service.sh` deve ser bom o suficiente se você precisar apenas executar um script de inicialização. Se precisar executar o script após a inicialização ser concluída, use `boot-completed.sh`. Se você quiser fazer algo após montar OverlayFS, use `post-mount.sh`.
 
-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.
+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 nos 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 no KernelSU, esse valor será definido como `true`.
@@ -118,7 +118,7 @@ Você pode usar a variável de ambiente `KSU` para determinar se um script está
 
 ### Diretório `system`
 
-O conteúdo deste diretório será sobreposto à partição /system do sistema usando OverlayFS após a inicialização do sistema. Isso significa que:
+O conteúdo deste diretório será sobreposto à partição `/system` do sistema usando OverlayFS após a inicialização do sistema. Isso significa que:
 
 1. Arquivos com o mesmo nome daqueles no diretório correspondente no sistema serão substituídos pelos arquivos deste diretório.
 2. Pastas com o mesmo nome daquelas no diretório correspondente no sistema serão mescladas com as pastas neste diretório.
@@ -154,7 +154,7 @@ Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube`
 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.
 :::
 
-Se você estiver interessado em OverlayFS, é recomendável ler a [documentação sobre OverlayFS](https://docs.kernel.org/filesystems/overlayfs.html) do Kernel Linux.
+Se você estiver interessado em OverlayFS, é recomendável ler a [documentação sobre OverlayFS](https://docs.kernel.org/filesystems/overlayfs.html) do kernel Linux.
 
 ### system.prop
 
@@ -166,7 +166,7 @@ Se o seu módulo exigir alguns patches adicionais do sepolicy, adicione essas re
 
 ## Instalador do módulo
 
-Um instalador do módulo KernelSU é um módulo KernelSU empacotado em um arquivo ZIP que pode ser atualizado no app gerenciador do KernelSU. O instalador do 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 gerenciador do KernelSU. O instalador do módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo ZIP.
 
 ```txt
 module.zip
@@ -188,15 +188,15 @@ Se você precisar personalizar o processo de instalação do módulo, opcionalme
 
 Se você quiser controlar e personalizar totalmente o processo de instalação, declare `SKIPUNZIP=1` em `customize.sh` para pular todas as etapas de instalação padrão. Ao fazer isso, seu `customize.sh` será responsável por instalar tudo sozinho.
 
-O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "Modo Autônomo" ativado. As seguintes variáveis ​​e funções estão disponíveis:
+O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o Modo Autônomo ativado. As seguintes variáveis ​​e funções estão disponíveis:
 
 #### Variáveis
 
 - `KSU` (bool): uma variável para marcar que o script está sendo executado no ambiente KernelSU, e o valor desta variável sempre será `true`. Você pode usá-lo para distinguir entre KernelSU e Magisk.
-- `KSU_VER` (string): a string da versão do KernelSU atualmente instalado (por exemplo, `v0.4.0`).
+- `KSU_VER` (string): a string da versão do KernelSU atualmente instalado (por exemplo: `v0.4.0`).
 - `KSU_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do usuário (por exemplo: `10672`).
 - `KSU_KERNEL_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do kernel (por exemplo: `10672`).
-- `BOOTMODE` (bool): sempre seja `true` no KernelSU.
+- `BOOTMODE` (bool): sempre será `true` no KernelSU.
 - `MODPATH` (path): o caminho onde os arquivos do seu módulo devem ser instalados.
 - `TMPDIR` (path): um lugar onde você pode armazenar arquivos temporariamente.
 - `ZIPFILE` (path): ZIP de instalação do seu módulo.
@@ -213,7 +213,7 @@ No KernelSU, `MAGISK_VER_CODE` é sempre `25200` e `MAGISK_VER` é sempre `v25.2
 ```txt
 ui_print <msg>
     imprima <msg> no console
-    Evite usar 'echo', pois ele não será exibido no console de recuperação personalizado
+    Evite usar 'echo', pois ele não será exibido no console de recovery personalizado
 
 abort <msg>
     imprima mensagem de erro <msg> para consolar e encerrar a instalação
@@ -229,7 +229,7 @@ set_perm <target> <owner> <group> <permission> [context]
 set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
     se [context] não está definido, o padrão é "u:object_r:system_file:s0"
     para todos os arquivos em <directory>, ele chamará:
-       contexto de permissão de arquivo do grupo proprietário do arquivo set_perm
+       set_perm arquivo proprietário do grupo filepermission
     para todos os diretórios em <directory> (including itself), ele vai ligar:
        set_perm dir owner group dirpermission context
 ```
@@ -258,6 +258,6 @@ No KernelSU, os scripts de inicialização são divididos em dois tipos com base
 - Scripts de módulo
   - Colocado na própria pasta do módulo.
   - Executado apenas se o módulo estiver ativado.
-  - `post-fs-data.sh` é executado no modo post-fs-data, `service.sh` é executado no modo de serviço late_start, `boot-completed.sh` é executado na inicialização concluída e `post-mount.sh` é executado em OverlayFS montado.
+  - `post-fs-data.sh` é executado no modo post-fs-data, `service.sh` é executado no modo de serviço late_start, `boot-completed.sh` é executado na inicialização concluída e `post-mount.sh` é executado no OverlayFS montado.
 
-Todos os scripts de inicialização serão executados no shell BusyBox `ash` do KernelSU com o "Modo Autônomo" ativado.
+Todos os scripts de inicialização serão executados no shell BusyBox `ash` do KernelSU com o Modo Autônomo ativado.

website/docs/pt_BR/guide/rescue-from-bootloop.md

@@ -6,7 +6,7 @@ Ao atualizar um dispositivo, podemos encontrar situações em que o dispositivo
 
 No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao flashar a partição boot:
 
-1. Você atualizou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu telefone for `gz`, mas você atualizou uma imagem no formato `lz4`, o telefone não será capaz de inicializar.
+1. Você flashou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu telefone for `gz`, mas você flashou uma imagem no formato `lz4`, o telefone não será capaz de inicializar.
 2. Seu telefone precisa desativar a verificação AVB para inicializar corretamente (geralmente exigindo a limpeza de todos os dados do telefone).
 3. Seu kernel tem alguns bugs ou não é adequado para o flash do seu telefone.
 
@@ -14,7 +14,7 @@ Não importa qual seja a situação, você pode recuperar **flashando a imagem d
 
 ## Bloqueio por módulos
 
-A instalação de módulos pode ser uma causa mais comum de bloqueio do seu dispositivo, mas devemos avisá-lo seriamente: **NÃO INSTALE MÓDULOS DE FONTES DESCONHECIDAS**! Como os módulos têm privilégios root, eles podem causar danos irreversíveis ao seu dispositivo!
+A instalação de módulos pode ser uma causa mais comum de bloqueio do seu dispositivo, mas devemos avisá-lo seriamente: **NÃO INSTALE MÓDULOS DE FONTES DESCONHECIDAS!** Como os módulos têm privilégios root, eles podem causar danos irreversíveis ao seu dispositivo!
 
 ### Módulos normais
 
@@ -31,14 +31,14 @@ Portanto, o método mais simples e comumente usado para recuperar seu dispositiv
 
 #### Recupere pressionando o botão de diminuir volume
 
-Se as atualizações AB ainda não resolverem o problema, você pode tentar usar o **Modo de Segurança**. No Modo de Segurança, todos os módulos estão desabilitados.
+Se a Atualização AB ainda não resolveu o problema, você pode tentar usar o **Modo de Segurança**. No Modo de Segurança, todos os módulos estão desativados.
 
 Existem duas maneiras de entrar no Modo de Segurança:
 
 1. O Modo de Segurança integrado de alguns sistemas. Alguns sistemas possuem um Modo de Segurança integrado que pode ser acessado pressionando longamente o botão de diminuir volume, enquanto outros (como a MIUI) podem ativar o Modo de Segurança no Recovery. Ao entrar no Modo de Segurança do sistema, o KernelSU também entrará no Modo de Segurança e desativará automaticamente os módulos.
 2. O Modo de Segurança integrado do KernelSU. O método de operação é **pressionar a tecla de diminuir volume continuamente por mais de três vezes** após a primeira tela de inicialização.
 
-Após entrar no Modo de Segurança, todos os módulos na página de módulos do gerenciador do KernelSU são desabilitados, mas você pode executar as operações de "desinstalação" para desinstalar quaisquer módulos que possam estar causando problemas.
+Após entrar no Modo de Segurança, todos os módulos na página de módulos do gerenciador do KernelSU são desativados, mas você pode executar as operações de "desinstalação" para desinstalar quaisquer módulos que possam estar causando problemas.
 
 O Modo de Segurança integrado é implementado no kernel, portanto não há possibilidade de perder eventos importantes devido à interceptação. No entanto, para kernels não GKI, a integração manual do código pode ser necessária e você pode consultar a documentação oficial para obter orientação.
 
@@ -46,5 +46,5 @@ O Modo de Segurança integrado é implementado no kernel, portanto não há poss
 
 Se os métodos acima não conseguirem recuperar seu dispositivo, é altamente provável que o módulo que você instalou tenha operações maliciosas ou tenha danificado seu dispositivo por outros meios. Neste caso, existem apenas duas sugestões:
 
-1. Limpe os dados e instale o sistema oficial.
+1. Limpar os dados e instalar o sistema oficial.
-2. Consulte o serviço pós-venda.
+2. Consultar o serviço pós-venda.

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

@@ -1,6 +1,6 @@
 # O que é KernelSU?
 
-O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo kernel e concede permissão root ao app do espaço do usuário diretamente no espaço do kernel.
+O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo kernel e concede privilégios root ao app do espaço do usuário diretamente no espaço do kernel.
 
 ## Características
 
@@ -12,9 +12,9 @@ E também, o KernelSU fornece um sistema de módulos via OverlayFS, que permite
 
 Por favor, consulte: [Instalação](installation)
 
-## Como construir o KernelSU?
+## Como compilar o KernelSU?
 
-Por favor, consulte: [Como construir?](how-to-build)
+Por favor, consulte: [Como compilar?](how-to-build)
 
 ## Discussão
 

website/docs/pt_BR/index.md

@@ -22,7 +22,7 @@ features:
     details: Como o nome sugere, KernelSU funciona no kernel Linux, dando-lhe mais controle sobre os apps do espaço do usuário.
   - title: Controle de acesso root
     details: Somente apps permitidos podem acessar ou ver su, todos os outros apps não estão cientes disso.
-  - title: Privilégios de root personalizáveis
+  - title: Privilégios root personalizáveis
-    details: KernelSU permite a personalização de su, uid, gid, grupos, capacidades e regras SELinux, bloqueando privilégios de root.
+    details: KernelSU permite a personalização de su, uid, gid, grupos, capacidades e regras do SELinux, bloqueando privilégios root.
   - title: Módulos
     details: Os módulos podem modificar /system sem sistema usando OverlayFS permitindo uma grande potência.