website: update translation (#1322)

This commit is contained in:
igor
2024-01-31 00:16:57 -03:00
committed by GitHub
parent 883a3e3407
commit 4b1fb121b4
4 changed files with 5 additions and 7 deletions

View File

@@ -69,6 +69,6 @@ Of course. But KernelSU doesn't have builtin hosts support, you can install [sys
## Why is there a huge 1T file?
The 1T size `modules.img` is a disk image file, **don't worry about its size**, it's a special type of file known as a [sparse file](https://en.wikipedia.org/wiki/Sparse_file), its actual size is only the size of the module you use, and it will dynamically shrink after you delete the module; it does not actually occupy 1T of disk space (actually your mobile phone may not have that much space) .
The 1T size `modules.img` is a disk image file, **don't worry about its size**, it's a special type of file known as a [sparse file](https://en.wikipedia.org/wiki/Sparse_file), its actual size is only the size of the module you use, and it will dynamically shrink after you delete the module; it does not actually occupy 1T of disk space (actually your mobile phone may not have that much space).
If you're really unhappy with the size of this file, you can use the `resize2fs -M` command to make it the actual size; but the module may not work properly at this time, and we won't provide any support for this.

View File

@@ -26,4 +26,3 @@ features:
details: KernelSU allows customization of `su`'s uid, gid, groups, capabilities, and SELinux rules, locking up root privileges.
- title: Modules
details: Modules may modify /system systemlessly using overlayfs enabling great power.

View File

@@ -67,8 +67,8 @@ Não recomendamos que você modifique a partição do sistema diretamente. Você
Claro. Mas o KernelSU não tem suporte a hosts integrados, você pode instalar [systemless-hosts](https://github.com/symbuzzer/systemless-hosts-KernelSU-module) para fazer isso.
## Por que há um arquivo enorme de 256 GB?
## Por que existe um enorme arquivo de 1T?
O arquivo de tamanho 256 GB `modules.img` é um arquivo de imagem de disco, **não se preocupe com seu tamanho**, é um tipo especial de arquivo conhecido como [arquivo esparso](https://en.wikipedia.org/wiki/Sparse_file), seu tamanho real é apenas o tamanho do módulo que você está usando, e ele diminuirá dinamicamente após você excluir o módulo; ele não ocupa realmente 256 GB de espaço em disco (na verdade, seu telefone celular pode não ter tanto espaço).
O arquivo `modules.img` de 1T é um arquivo de imagem de disco, **não se preocupe com seu tamanho**, é um tipo especial de arquivo conhecido como [arquivo esparso](https://en.wikipedia.org/wiki/Sparse_file), seu tamanho real é apenas o tamanho do módulo que você usa e diminuirá dinamicamente após você excluir o módulo. Na verdade, ele não ocupa 1T de espaço em disco (na verdade, seu celular pode não ter tanto espaço).
Se você estiver realmente insatisfeito com o tamanho deste arquivo, pode usar o comando `resize2fs -M` para torná-lo do tamanho real; no entanto, o módulo pode não funcionar corretamente neste momento, e não forneceremos suporte para isso.
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.

View File

@@ -1,4 +1,3 @@
# 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".
@@ -105,7 +104,7 @@ description=<string>
### Shell scripts
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`.
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.