website: fix translation readme: fix translation (#1297)

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

@@ -106,7 +106,7 @@ Se você realmente precisa conceder permissões de root ao ADB (por exemplo, com
 
 ### 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”.
+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:
 

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

@@ -25,4 +25,4 @@ Aqui estão algumas diferenças:
 - 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!**
 - O KernelSU não suporta arquivos `.replace`, entretanto, o KernelSU suporta as variáveis ​​`REMOVE` e `REPLACE` para remover ou substituir arquivos e pastas.
 - O KernelSU adiciona o estágio `boot-completed` para executar alguns scripts na inicialização concluída.
-- O KernelSU adiciona o estágio `post-mount` para executar alguns scripts após montar overlayfs.
+- O KernelSU adiciona o estágio `post-mount` para executar alguns scripts após montar OverlayFS.

website/docs/pt_BR/guide/faq.md

@@ -1,4 +1,4 @@
-# FAQ
+# Perguntas frequentes
 
 ## KernelSU oferece suporte ao meu dispositivo?
 

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

@@ -2,7 +2,7 @@
 
 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 imagens boot 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 boot.img não GKI. Mas você mesmo pode construir 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.
 
@@ -33,7 +33,7 @@ E construa seu kernel novamente, KernelSU deve funcionar bem.
 
 Se você descobrir que o KPROBES ainda não está ativado, você pode tentar ativar `CONFIG_MODULES`. (Se ainda assim não surtir efeito, use `make menuconfig` para procurar outras dependências do KPROBES)
 
-Mas se você entrar em um bootloop quando o KernelSU for integrado, talvez o **kprobe esteja quebrado em seu kernel**, você deve corrigir o bug do kprobe ou usar o segundo caminho.
+Mas se você entrar em um bootloop quando o KernelSU for integrado, talvez o **kprobe esteja quebrado em seu kernel**. Você deve corrigir o bug do kprobe ou usar o segundo caminho.
 
 :::tip COMO VERIFICAR SE O KPROBE ESTÁ QUEBRADO?
 
@@ -64,9 +64,9 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
 
 Tenha em mente que em alguns dispositivos, seu defconfig pode estar em `arch/arm64/configs` ou em outros casos `arch/arm64/configs/vendor/your_defconfig`. Por exemplo, em seu defconfig, habilite `CONFIG_KSU` com y para habilitar ou n para desabilitar. Seu caminho será algo como:
 `arch/arm64/configs/...` 
-```sh
-+# KernelSU
-+CONFIG_KSU=y
+```
+# KernelSU
+CONFIG_KSU=y
 ```
 
 Em seguida, adicione chamadas KernelSU à fonte do kernel. Aqui estão alguns patches para referência:
@@ -117,8 +117,8 @@ index 05036d819197..965b84d486b8 100644
 +			 int *flags);
 +#endif
  /*
-  * access() needs to use the real uid/gid, not the effective uid/gid.
-  * We do this by temporarily clearing all FS-related capabilities and
+  * access() precisa usar o uid/gid real, não o uid/gid efetivo.
+  * Fazemos isso limpando temporariamente todos os recursos relacionados ao FS e
 @@ -355,6 +357,7 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
   */
  long do_faccessat(int dfd, const char __user *filename, int mode)
@@ -177,8 +177,8 @@ index 376543199b5a..82adcef03ecc 100644
 +#endif
 +
  /**
-  * vfs_statx - Get basic and extra attributes by filename
-  * @dfd: A file descriptor representing the base dir for a relative filename
+  * vfs_statx - Obtenha atributos básicos e extras por filename
+  * @dfd: Um descritor de arquivo que representa o diretório base para um filename relativo
 @@ -170,6 +172,7 @@ int vfs_statx(int dfd, const char __user *filename, int flags,
  	int error = -EINVAL;
  	unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
@@ -246,8 +246,8 @@ index 2ff887661237..e758d7db7663 100644
 +#endif
 +
  /*
-  * access() needs to use the real uid/gid, not the effective uid/gid.
-  * We do this by temporarily clearing all FS-related capabilities and
+  * access() precisa usar o uid/gid real, não o uid/gid efetivo.
+  * Fazemos isso limpando temporariamente todos os recursos relacionados ao FS e
 @@ -370,6 +373,8 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
  	int res;
  	unsigned int lookup_flags = LOOKUP_FOLLOW;

website/docs/pt_BR/guide/installation.md

@@ -79,7 +79,7 @@ Normalmente, existem três arquivos de inicialização em formatos diferentes no
 ::: info INFORMAÇÕES
 1. Você pode usar o magiskboot para obter o formato de compactação de seu boot original; é claro que você também pode perguntar a outras pessoas 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.
+3. Para dispositivos Pixel, siga as instruções abaixo:
 :::
 
 ### Flash boot.img para o dispositivo
@@ -118,7 +118,7 @@ Dessa forma, é necessário que o app Kernel Flasher tenha permissões root. Voc
 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 (backup primeiro).
+PS. 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
 
@@ -129,7 +129,7 @@ Para alguns dispositivos, o formato boot.img não é tão comum como `lz4`, `gz`
 1. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
 2. [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci)
 
-A versão oficial do `magiskboot` só pode rodar em dispositivos Android, se você quiser rodar no PC, você pode tentar a segunda.
+A versão oficial do `magiskboot` só pode rodar em dispositivos Android, se você quiser rodar no PC, você pode tentar a segunda opção.
 
 ::: tip DICA
 Android-Image-Kitchen não é recomendado agora, porque ele não lida corretamente com os metadados de inicialização (como o nível do patch de segurança). Portanto, pode não funcionar em alguns dispositivos.
@@ -137,14 +137,14 @@ 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.
 
 ### Usando o magiskboot em dispositivos Android {#using-magiskboot-on-Android-devices}
 
 1. Baixe o Magisk mais recente em [GitHub Releases](https://github.com/topjohnwu/Magisk/releases).
-2. Renomeie o `Magisk-*(version).apk` para `Magisk-*.zip` e descompacte-o.
+2. Renomeie o `Magisk-*(versão).apk` para `Magisk-*.zip` e descompacte-o.
 3. Envie `Magisk-*/lib/arm64-v8a/libmagiskboot.so` para o seu dispositivo por ADB: `adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`.
 4. Envie o boot.img padrão e Image em AnyKernel3 para o seu dispositivo.
 5. Entre no ADB shell e no diretório cd `/data/local/tmp/`, em seguida, `chmod +x magiskboot`.

website/docs/pt_BR/guide/module.md

@@ -1,3 +1,4 @@
+
 # Guias de módulo
 
 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".
@@ -114,12 +115,12 @@ 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.
 
-Se você deseja excluir um arquivo ou pasta no diretório original do sistema, você precisa criar um arquivo com o mesmo nome do arquivo/pasta no diretório do módulo usando `mknod filename c 0 0`. Dessa forma, o sistema overlayfs irá automaticamente "branquear" este arquivo como se ele tivesse sido excluído (a partição /system não foi realmente alterada).
+Se você deseja excluir um arquivo ou pasta no diretório original do sistema, você precisa criar um arquivo com o mesmo nome do arquivo/pasta no diretório do módulo usando `mknod filename c 0 0`. Dessa forma, o sistema OverlayFS irá automaticamente "branquear" este arquivo como se ele tivesse sido excluído (a partição /system não foi realmente alterada).
 
 Você também pode declarar uma variável chamada `REMOVE` contendo uma lista de diretórios em `customize.sh` para executar operações de remoção, e o KernelSU executará automaticamente `mknod <TARGET> c 0 0` nos diretórios correspondentes do módulo. Por exemplo:
 
@@ -132,7 +133,7 @@ REMOVE="
 
 A lista acima irá executar `mknod $MODPATH/system/app/YouTube c 0 0` e `mknod $MODPATH/system/app/Bloatware c 0 0`; e `/system/app/YouTube` e `/system/app/Bloatware` serão removidos após o módulo entrar em vigor.
 
-Se você deseja substituir um diretório no sistema, você precisa criar um diretório com o mesmo caminho no diretório do módulo e, em seguida, definir o atributo `setfattr -n trusted.overlay.opaque -v y <TARGET>` para este diretório. Desta forma, o sistema overlayfs substituirá automaticamente o diretório correspondente no sistema (sem alterar a partição /system).
+Se você deseja substituir um diretório no sistema, você precisa criar um diretório com o mesmo caminho no diretório do módulo e, em seguida, definir o atributo `setfattr -n trusted.overlay.opaque -v y <TARGET>` para este diretório. Desta forma, o sistema OverlayFS substituirá automaticamente o diretório correspondente no sistema (sem alterar a partição /system).
 
 Você pode declarar uma variável chamada `REPLACE` em seu arquivo `customize.sh`, que inclui uma lista de diretórios a serem substituídos, e o KernelSU executará automaticamente as operações correspondentes em seu diretório de módulo. Por exemplo:
 
@@ -147,10 +148,10 @@ Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube`
 
 ::: 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.
+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
 
@@ -254,6 +255,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 em OverlayFS montado.
 
 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/what-is-kernelsu.md

@@ -6,7 +6,7 @@ O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo
 
 A principal característica do KernelSU é que ele é **baseado em kernel**. O KernelSU funciona no modo kernel, portanto pode fornecer uma interface de kernel que nunca tivemos antes. Por exemplo, podemos adicionar um ponto de interrupção de hardware a qualquer processo no modo kernel, podemos acessar a memória física de qualquer processo sem que ninguém perceba, podemos interceptar qualquer syscall no espaço do kernel, etc.
 
-E também, o KernelSU fornece um sistema de módulos via overlayfs, que permite carregar seu plugin personalizado no sistema. Ele também fornece um mecanismo para modificar arquivos na partição `/system`.
+E também, o KernelSU fornece um sistema de módulos via OverlayFS, que permite carregar seu plugin personalizado no sistema. Ele também fornece um mecanismo para modificar arquivos na partição `/system`.
 
 ## Como usar o KernelSU?
 

website/docs/pt_BR/index.md

@@ -25,4 +25,4 @@ features:
   - title: Privilégios de root personalizáveis
     details: KernelSU permite a personalização de uid, gid, grupos, capacidades e regras SELinux do su, bloqueando privilégios de root.
   - title: Módulos
-    details: Os módulos podem modificar /system sem sistema usando overlayfs permitindo uma grande potência.
+    details: Os módulos podem modificar /system sem sistema usando OverlayFS permitindo uma grande potência.