ci: Build pt-BR docs and fix Portuguese wording (#481)

.github/workflows/docs.yml

@@ -21,11 +21,12 @@ jobs:
         with:
           python-version: 3.x
       - run: pip install zensical
-      - run: zensical build -f docs/zensical.toml --clean
-      - run: zensical build -f docs/zensical.ja-JP.toml
-      - run: zensical build -f docs/zensical.zh-CN.toml
-      - uses: actions/upload-pages-artifact@v4
-        with:
-          path: docs/site
+      - run: zensical build -f docs/zensical.toml --clean
+      - run: zensical build -f docs/zensical.ja-JP.toml
+      - run: zensical build -f docs/zensical.zh-CN.toml
+      - run: zensical build -f docs/zensical.pt-BR.toml
+      - uses: actions/upload-pages-artifact@v4
+        with:
+          path: docs/site
       - uses: actions/deploy-pages@v4
         id: deployment

docs/pt-BR/explanation/models-and-providers.md

@@ -14,11 +14,11 @@ O Koharu baixa automaticamente os modelos de visão necessários na primeira vez
 
 O stack padrão atual inclui:
 
-- [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) para detection conjunta de blocos de texto e balões de fala
-- [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector) para masks de segmentation de texto
+- [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) para detecção conjunta de blocos de texto e balões de fala
+- [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector) para máscaras de segmentação de texto
 - [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5) para reconhecimento de texto por OCR
 - [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting) para o inpainting padrão
-- [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) para detection de fonte e cor
+- [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) para detecção de fonte e cor
 
 Alguns modelos são usados diretamente dos repositórios upstream do Hugging Face, enquanto os pesos convertidos em `safetensors` são hospedados no [Hugging Face](https://huggingface.co/mayocream) quando o Koharu precisa de um pacote amigável para Rust.
 
@@ -26,16 +26,16 @@ Alguns modelos são usados diretamente dos repositórios upstream do Hugging Fac
 
 | Modelo                        | Tipo de modelo          | Por que o Koharu o usa                                     |
 | ---------------------------- | ---------------------- | ------------------------------------------------------- |
-| `comic-text-bubble-detector` | object detector        | encontra blocos de texto e regiões de balão de fala em uma única passagem |
-| `comic-text-detector`        | rede de segmentation   | produz um mask de texto para limpeza                        |
+| `comic-text-bubble-detector` | detector de objetos    | encontra blocos de texto e regiões de balão de fala em uma única passagem |
+| `comic-text-detector`        | rede de segmentação    | produz uma máscara de texto para limpeza                    |
 | `PaddleOCR-VL-1.5`           | modelo de linguagem visual  | lê texto recortado em tokens de texto                     |
 | `aot-inpainting`             | rede de inpainting     | reconstrói regiões de imagem mascaradas após a remoção do texto    |
 | `YuzuMarker.FontDetection`   | classificador / regressor | estima dicas de fonte e estilo para a renderização            |
 
-A escolha de design importante é que o Koharu não usa um modelo para cada tarefa de página. Detection, segmentation, OCR e inpainting precisam de formatos de saída diferentes:
+A escolha de design importante é que o Koharu não usa um modelo para cada tarefa de página. Detecção, segmentação, OCR e inpainting precisam de formatos de saída diferentes:
 
-- a detection conjunta quer blocos de texto e regiões de balão
-- a segmentation quer masks por pixel
+- a detecção conjunta quer blocos de texto e regiões de balão
+- a segmentação quer máscaras por pixel
 - o OCR quer texto
 - o inpainting quer pixels restaurados
 

docs/pt-BR/explanation/technical-deep-dive.md

@@ -4,7 +4,7 @@ title: Mergulho Técnico Profundo
 
 # Mergulho Técnico Profundo
 
-Esta página cobre a estrutura técnica da pipeline de mangá do Koharu: o que cada modelo faz, como os estágios se encaixam e por que detection de texto e balão, masks de segmentation, OCR, inpainting e tradução são tratados separadamente.
+Esta página cobre a estrutura técnica da pipeline de mangá do Koharu: o que cada modelo faz, como os estágios se encaixam e por que detecção de texto e balão, máscaras de segmentação, OCR, inpainting e tradução são tratados separadamente.
 
 ## A pipeline da página em termos de implementação
 
@@ -13,14 +13,14 @@ flowchart TD
     A[Página de entrada] --> B[comic-text-bubble-detector]
     A --> C[comic-text-detector-seg]
     B --> D[Blocos de texto + balões]
-    C --> E[Mask de segmentation]
+    C --> E[Máscara de segmentação]
     A --> F[Detector de fonte YuzuMarker]
     D --> C
     D --> G[OCR de crop PaddleOCR-VL]
     E --> H[AOT inpainting]
     G --> I[LLM local ou remoto]
-    F --> J[Dicas de estilo do renderer]
-    H --> K[Renderer]
+    F --> J[Dicas de estilo do renderizador]
+    H --> K[Renderizador]
     I --> K
     J --> K
     K --> L[Página renderizada / PSD]
@@ -28,8 +28,8 @@ flowchart TD
 
 No nível do código, a pipeline pública é `Detect -> OCR -> Inpaint -> LLM Generate -> Render`, mas o estágio detect já está fazendo três trabalhos distintos:
 
-- detection de texto e balão
-- segmentation de primeiro plano do texto
+- detecção de texto e balão
+- segmentação de primeiro plano do texto
 - estimativa de fonte e cor
 
 Esse design é intencional. Uma ferramenta de tradução de mangá precisa tanto de estrutura da página quanto de precisão ao nível do pixel.
@@ -38,8 +38,8 @@ Esse design é intencional. Uma ferramenta de tradução de mangá precisa tanto
 
 | Componente | Modelo padrão | Tipo de modelo | Trabalho principal no Koharu |
 | --- | --- | --- | --- |
-| Detection de texto e balão | [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) | object detector | encontrar blocos de texto e regiões de balão de fala |
-| Segmentation | [comic-text-detector](https://github.com/dmMaze/comic-text-detector) | rede de segmentation de texto | produzir um mask denso de texto para limpeza |
+| Detecção de texto e balão | [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) | detector de objetos | encontrar blocos de texto e regiões de balão de fala |
+| Segmentação | [comic-text-detector](https://github.com/dmMaze/comic-text-detector) | rede de segmentação de texto | produzir uma máscara densa de texto para limpeza |
 | OCR | [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5) | modelo de linguagem visual | ler regiões de texto recortadas em texto Unicode |
 | Inpainting | [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting) / [manga-image-translator](https://github.com/zyddnys/manga-image-translator) | rede de inpainting de imagem | preencher regiões mascaradas após a remoção do texto |
 | Dicas de fonte | [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) | classificador / regressor de imagem | estimar família da fonte, cores e dicas de traço |
@@ -47,9 +47,9 @@ Esse design é intencional. Uma ferramenta de tradução de mangá precisa tanto
 
 Alternativas internas opcionais ainda estão disponíveis. As principais são [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) como detector alternativo e engine de análise de layout, [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation) como detector dedicado de balões e [lama-manga](https://huggingface.co/mayocream/lama-manga) como inpainter alternativo.
 
-## Por que detection de texto e balão importa em páginas de mangá
+## Por que a detecção de texto e balão importa em páginas de mangá
 
-Detection não é só "achar caixas ao redor do texto". Em páginas de mangá, ela precisa responder a várias perguntas estruturais:
+Detecção não é só "achar caixas ao redor do texto". Em páginas de mangá, ela precisa responder a várias perguntas estruturais:
 
 - quais regiões são parecidas com texto
 - onde estão os balões de fala
@@ -69,15 +69,15 @@ O Koharu primeiro converte a saída do detector em registros `TextBlock` e depoi
 Na implementação atual, o estágio detect padrão:
 
 - executa a versão em Candle de `ogkalu/comic-text-and-bubble-detector`
-- converte as detections de texto em valores `TextBlock`
-- converte as detections de balões em valores `BubbleRegion`
+- converte as detecções de texto em valores `TextBlock`
+- converte as detecções de balões em valores `BubbleRegion`
 - ordena os blocos de texto na ordem de leitura de mangá antes do OCR
 
 Se você preferir um detector no estilo document-layout, o `PP-DocLayoutV3` ainda está disponível como engine alternativo. Ele simplesmente não é mais o padrão.
 
-## O que é um mask de segmentation
+## O que é uma máscara de segmentação
 
-Um mask de segmentation é um mapa do tamanho da imagem no qual cada pixel indica se ele pertence a uma classe-alvo. No caso do Koharu, essa classe é efetivamente "primeiro plano do texto que deve ser removido mais tarde durante a limpeza".
+Uma máscara de segmentação é um mapa do tamanho da imagem no qual cada pixel indica se ele pertence a uma classe-alvo. No caso do Koharu, essa classe é efetivamente "primeiro plano do texto que deve ser removido mais tarde durante a limpeza".
 
 Isso é diferente de uma bounding box:
 
@@ -85,47 +85,47 @@ Isso é diferente de uma bounding box:
 | --- | --- | --- |
 | Bounding box | região retangular grosseira | seleção de crop para OCR, ordenação, edição na UI |
 | Polígono | contorno geométrico mais justo | geometria ao nível de linha |
-| Mask de segmentation | mapa de primeiro plano por pixel | inpainting e limpeza precisa |
+| Máscara de segmentação | mapa de primeiro plano por pixel | inpainting e limpeza precisa |
 
 ```mermaid
 flowchart LR
     A[Balão de fala] --> B[Caixa de layout]
-    A --> C[Mask de segmentation]
+    A --> C[Máscara de segmentação]
     B --> D[Crop para OCR]
     C --> E[Apagar pixels exatos do texto]
 ```
 
-No Koharu, o caminho de segmentation é intencionalmente separado do layout:
+No Koharu, o caminho de segmentação é intencionalmente separado do layout:
 
 - `comic-text-detector` produz um mapa de probabilidade em escala de cinza
 - o Koharu aplica threshold e dilata esse mapa com pós-processamento leve
-- o mask binário resultante se torna `doc.segment`
-- `aot-inpainting` então usa `doc.segment` como o mask de apagar e preencher para o inpainting
+- a máscara binária resultante se torna `doc.segment`
+- `aot-inpainting` então usa `doc.segment` como a máscara de apagar e preencher para o inpainting
 
-A etapa de limpeza ainda importa porque as probabilidades brutas de segmentation geralmente são suaves e ruidosas. O Koharu aplica threshold na predição e dilata o mask binário final para que a limpeza cubra bordas e contornos do texto em vez de deixar halos para trás.
+A etapa de limpeza ainda importa porque as probabilidades brutas de segmentação geralmente são suaves e ruidosas. O Koharu aplica threshold na predição e dilata a máscara binária final para que a limpeza cubra bordas e contornos do texto em vez de deixar halos para trás.
 
 ## Como os modelos de visão funcionam em teoria
 
-### Detection conjunta: blocos de texto e regiões de balão em uma única passagem
+### Detecção conjunta: blocos de texto e regiões de balão em uma única passagem
 
 [ogkalu/comic-text-and-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) é o detector padrão porque prevê os dois tipos de região com os quais o resto da pipeline mais se importa:
 
 - regiões parecidas com texto que devem se tornar `TextBlock`s
 - regiões de balão de fala que devem permanecer disponíveis para o editor e ferramentas downstream
 
-A versão em Candle do Koharu mapeia essas detections em estruturas de dados do documento e, em seguida, ordena os blocos de texto na ordem de leitura de mangá antes do OCR. Conceitualmente, isso está mais próximo de object detection ao nível de página do que do próprio OCR.
+A versão em Candle do Koharu mapeia essas detecções em estruturas de dados do documento e, em seguida, ordena os blocos de texto na ordem de leitura de mangá antes do OCR. Conceitualmente, isso está mais próximo de detecção de objetos ao nível de página do que do próprio OCR.
 
-### Segmentation: predição densa de texto por pixel
+### Segmentação: predição densa de texto por pixel
 
-O caminho `comic-text-detector` do Koharu é segmentation-first. A versão em Rust carrega:
+O caminho `comic-text-detector` do Koharu é segmentação-first. A versão em Rust carrega:
 
 - um backbone no estilo YOLOv5
-- um decoder U-Net para predição de mask
-- uma head DBNet opcional para modo de detection completa
+- um decoder U-Net para predição de máscara
+- uma head DBNet opcional para modo de detecção completa
 
-A pipeline de página padrão usa o caminho apenas de segmentation porque o Koharu já obtém blocos de texto de `comic-text-bubble-detector`. Isso significa que o Koharu combina:
+A pipeline de página padrão usa o caminho apenas de segmentação porque o Koharu já obtém blocos de texto de `comic-text-bubble-detector`. Isso significa que o Koharu combina:
 
-- um modelo que é bom em detection de região ao nível de página
+- um modelo que é bom em detecção de região ao nível de página
 - um modelo que é bom em primeiro plano de texto ao nível de pixel
 
 Isso se encaixa muito melhor para limpeza do que depender apenas de caixas.
@@ -166,7 +166,7 @@ A versão em Candle do Koharu segue de perto a forma de inferência upstream:
 
 1. redimensiona páginas grandes para um lado máximo configurável
 2. faz padding da imagem de trabalho para um formato múltiplo de 8
-3. alimenta a imagem RGB mascarada mais um mask binário de texto na rede
+3. alimenta a imagem RGB mascarada mais uma máscara binária de texto na rede
 4. compõe os pixels previstos de volta no tamanho original da imagem
 
 `lama-manga` ainda está disponível como engine alternativo se você quiser o comportamento baseado em Fourier do LaMa, mas ele não é mais o padrão.
@@ -194,11 +194,11 @@ O Koharu mantém as etapas de entendimento de imagem locais mesmo quando você e
 Alguns detalhes são fáceis de perder se você ler apenas a documentação de alto nível:
 
 - o estágio detect padrão é `comic-text-bubble-detector`, não `PP-DocLayoutV3`
-- `comic-text-detector-seg` ainda carrega o caminho apenas de segmentation de `comic-text-detector` para `doc.segment`
-- o mask de segmentation é atualmente construído a partir de thresholding mais dilatação, não do caminho antigo de refinamento ciente de blocos
+- `comic-text-detector-seg` ainda carrega o caminho apenas de segmentação de `comic-text-detector` para `doc.segment`
+- a máscara de segmentação é atualmente construída a partir de thresholding mais dilatação, não do caminho antigo de refinamento ciente de blocos
 - o OCR é executado em imagens de blocos de texto recortados, não na página inteira original
 - o wrapper de OCR usa o caminho multimodal do llama.cpp e o prompt de tarefa `OCR:`
-- o inpainting consome `doc.segment`, então masks ruins levam diretamente a limpezas ruins
+- o inpainting consome `doc.segment`, então máscaras ruins levam diretamente a limpezas ruins
 - o inpainter padrão é `aot-inpainting`, enquanto `lama-manga` permanece selecionável como alternativa
 - a predição de fonte é normalizada antes da renderização para que cores próximas do preto e do branco sejam ajustadas para valores mais limpos
 
@@ -221,10 +221,10 @@ Alguns detalhes são fáceis de perder se você ler apenas a documentação de a
 Essas páginas são úteis se você quiser a teoria geral e diagramas de visão geral antes de mergulhar nos model cards:
 
 - [Transformada de Fourier](https://en.wikipedia.org/wiki/Fourier_transform)
-- [Image segmentation](https://en.wikipedia.org/wiki/Image_segmentation)
+- [Segmentação de imagens](https://en.wikipedia.org/wiki/Image_segmentation)
 - [Optical character recognition](https://en.wikipedia.org/wiki/Optical_character_recognition)
 - [Transformer (arquitetura de deep learning)](https://en.wikipedia.org/wiki/Transformer_(deep_learning_architecture))
-- [Object detection](https://en.wikipedia.org/wiki/Object_detection)
+- [Detecção de objetos](https://en.wikipedia.org/wiki/Object_detection)
 - [Inpainting](https://en.wikipedia.org/wiki/Inpainting)
 
 Esses links da Wikipédia são referências de fundo. Para o comportamento específico do Koharu e as escolhas reais de modelos, prefira os model cards oficiais e a árvore de código-fonte.

docs/pt-BR/explanation/text-rendering-and-vertical-cjk-layout.md

@@ -1,11 +1,11 @@
 ---
 title: Renderização de Texto e Layout Vertical CJK
-description: Como o renderer de texto do Koharu funciona, por que a renderização de texto é difícil e o que a implementação atual faz para o layout vertical CJK de mangá.
+description: Como o renderizador de texto do Koharu funciona, por que a renderização de texto é difícil e o que a implementação atual faz para o layout vertical CJK de mangá.
 ---
 
 # Renderização de Texto e Layout Vertical CJK
 
-A renderização de texto é uma das partes mais difíceis de um tradutor de mangá. Detection, OCR e inpainting decidem o que deve acontecer com a página, mas o renderer decide se o resultado ainda se lê como uma página de mangá finalizada em vez de uma sobreposição de debug.
+A renderização de texto é uma das partes mais difíceis de um tradutor de mangá. Detecção, OCR e inpainting decidem o que deve acontecer com a página, mas o renderizador decide se o resultado ainda se lê como uma página de mangá finalizada em vez de uma sobreposição de depuração.
 
 Uma referência externa útil é [Text Rendering Hates You](https://faultlore.com/blah/text-hates-you/) de Aria Desires. O ponto central se aplica diretamente ao Koharu: a renderização de texto não é um problema linear e limpo, e não existe uma resposta universalmente correta. Layout, shaping, fallback de fonte, rasterização e composição afetam uns aos outros.
 
@@ -13,7 +13,7 @@ O Koharu não tenta ser um mecanismo completo de publicação desktop. Ele busca
 
 ## Por que esse problema é difícil
 
-O artigo do Faultlore divide um renderer em um conjunto familiar de estágios:
+O artigo do Faultlore divide um renderizador em um conjunto familiar de estágios:
 
 ```mermaid
 flowchart LR
@@ -29,7 +29,7 @@ Essa divisão é útil, mas na prática os estágios não permanecem independent
 - você não pode fazer shaping de forma confiável sem conhecer a direção de escrita e as features OpenType
 - você não pode escolher uma única fonte para todo o texto porque as páginas de mangá misturam scripts, símbolos e emojis
 - você não pode simplesmente desenhar pontos de código um por um porque o texto real é moldado em runs de glifos
-- você não pode assumir que a caixa de um balão é a mesma coisa que os limites reais de tinta do renderer
+- você não pode assumir que a caixa de um balão é a mesma coisa que os limites reais de tinta do renderizador
 
 O texto vertical de mangá torna o problema ainda mais difícil:
 
@@ -40,7 +40,7 @@ O texto vertical de mangá torna o problema ainda mais difícil:
 
 ## O que o Koharu realmente faz
 
-No nível da implementação, o renderer vive no crate `koharu-renderer`, e a orquestração principal acontece em `koharu-app/src/renderer.rs`, `src/layout.rs`, `src/shape.rs`, `src/segment.rs` e `src/renderer.rs`.
+No nível da implementação, o renderizador vive no crate `koharu-renderer`, e a orquestração principal acontece em `koharu-app/src/renderer.rs`, `src/layout.rs`, `src/shape.rs`, `src/segment.rs` e `src/renderer.rs`.
 
 A pipeline para um `TextBlock` traduzido é aproximadamente:
 
@@ -74,12 +74,12 @@ O Koharu não força cegamente todo texto CJK para o modo vertical. A heurístic
 
 Isso significa que o layout vertical depende de ambos:
 
-- detection de script
+- detecção de script
 - a geometria da caixa de texto detectada ou ajustada pelo usuário
 
 Isso é simples de propósito. Ele corresponde a uma grande parcela do texto de balão de mangá e evita transformar cada legenda mista em texto vertical só porque contém um caractere japonês.
 
-Ainda é uma heurística, não um mecanismo geral de modo de escrita. Isso importa para casos extremos e é um dos limites atuais do renderer.
+Ainda é uma heurística, não um mecanismo geral de modo de escrita. Isso importa para casos extremos e é um dos limites atuais do renderizador.
 
 ## Como o CJK vertical é implementado
 
@@ -96,7 +96,7 @@ Quando o Koharu faz shaping de texto vertical, ele ativa as features OpenType:
 - `vert`
 - `vrt2`
 
-Essas são as alternativas verticais padrão expostas por fontes que realmente suportam escrita vertical. Essa é uma das principais razões pelas quais o renderer pode produzir um layout vertical CJK convincente em vez de parecer texto horizontal rotacionado.
+Essas são as alternativas verticais padrão expostas por fontes que realmente suportam escrita vertical. Essa é uma das principais razões pelas quais o renderizador pode produzir um layout vertical CJK convincente em vez de parecer texto horizontal rotacionado.
 
 Se a fonte tiver substituições apropriadas de glifos verticais, o Koharu pode usá-las. Se a fonte não tiver, o resultado degrada para o que a fonte fornecer.
 
@@ -127,7 +127,7 @@ Isso cobre casos como:
 - colchetes e marcas de canto
 - pontos médios e marcas similares
 
-Isso não é cosmético. É uma das razões pelas quais o caminho vertical atual parece mais intencional do que um renderer genérico de texto.
+Isso não é cosmético. É uma das razões pelas quais o caminho vertical atual parece mais intencional do que um renderizador genérico de texto.
 
 ### 5. Pontuação de ênfase é normalizada
 
@@ -145,7 +145,7 @@ Isso é importante porque:
 - pontuação vertical e formas alternativas de glifos podem ter extensões surpreendentes
 - glifos de contorno e de bitmap precisam pousar na mesma superfície final de forma confiável
 
-Na prática, essa passagem de limites é uma das razões pelas quais o renderer parece estável em vez de estar constantemente recortando a borda superior, inferior ou direita do texto.
+Na prática, essa passagem de limites é uma das razões pelas quais o renderizador parece estável em vez de estar constantemente recortando a borda superior, inferior ou direita do texto.
 
 ## Por que a saída é boa em balões de mangá
 
@@ -159,7 +159,7 @@ O Koharu acerta várias coisas de alto valor para o caso comum de mangá:
 - ele centraliza pontuação fullwidth no modo vertical
 - ele tem testes verificando especificamente a direção de fluxo vertical e a saída vertical em chinês e japonês
 
-Essa combinação é por que o renderer pode produzir texto vertical CJK que parece intencional e legível em vez de meramente "suportado".
+Essa combinação é por que o renderizador pode produzir texto vertical CJK que parece intencional e legível em vez de meramente "suportado".
 
 ## Quão perfeito é?
 
@@ -176,7 +176,7 @@ O Koharu é melhor entendido como:
 
 ## Limites atuais
 
-A base de código é bastante clara sobre onde o renderer ainda está incompleto.
+A base de código é bastante clara sobre onde o renderizador ainda está incompleto.
 
 ### O modo de escrita é heurístico
 
@@ -193,11 +193,11 @@ Isso funciona surpreendentemente bem para balões, mas ainda é uma heurística.
 
 ### O suporte da fonte importa muito
 
-As alternativas verticais só ficam tão boas quanto a fonte escolhida permite. Se a fonte do sistema não contiver formas verticais adequadas, o renderer não pode inventar uma fonte CJK profissional completa do zero.
+As alternativas verticais só ficam tão boas quanto a fonte escolhida permite. Se a fonte do sistema não contiver formas verticais adequadas, o renderizador não pode inventar uma fonte CJK profissional completa do zero.
 
 ### Sem features completas de engine de publicação
 
-O Koharu não está tentando fazer todas as features avançadas de texto que você esperaria de um sistema completo de composição. O renderer atual não é uma implementação completa de coisas como:
+O Koharu não está tentando fazer todas as features avançadas de texto que você esperaria de um sistema completo de composição. O renderizador atual não é uma implementação completa de coisas como:
 
 - anotação ruby
 - warichu e outras features avançadas de layout japonês
@@ -206,7 +206,7 @@ O Koharu não está tentando fazer todas as features avançadas de texto que voc
 
 ### O tamanho da tradução ainda muda a qualidade do layout
 
-Mesmo com um bom shaping, uma tradução pode simplesmente ser muito longa ou muito desajeitada para o balão disponível. O renderer pode encaixar e alinhar texto, mas nem sempre consegue transformar uma geometria de bloco ruim ou uma tradução excessivamente verbosa em uma letragem perfeita.
+Mesmo com um bom shaping, uma tradução pode simplesmente ser muito longa ou muito desajeitada para o balão disponível. O renderizador pode encaixar e alinhar texto, mas nem sempre consegue transformar uma geometria de bloco ruim ou uma tradução excessivamente verbosa em uma letragem perfeita.
 
 ## Por que o Koharu não apenas rotaciona o texto
 
@@ -222,12 +222,12 @@ Em vez disso, o Koharu empurra o tratamento vertical de volta para os estágios
 
 ## Referência externa que vale a leitura
 
-[Text Rendering Hates You](https://faultlore.com/blah/text-hates-you/) é útil porque explica o problema do renderer de uma forma agnóstica à linguagem. O stack do Koharu é diferente de um engine de navegador, mas as mesmas lições centrais aparecem aqui:
+[Text Rendering Hates You](https://faultlore.com/blah/text-hates-you/) é útil porque explica o problema do renderizador de uma forma agnóstica à linguagem. O stack do Koharu é diferente de um engine de navegador, mas as mesmas lições centrais aparecem aqui:
 
 - shaping não é opcional
 - fontes de fallback são inevitáveis
 - layout e shaping dependem um do outro
 - renderização de texto "perfeita" é principalmente uma história que as pessoas contam antes de implementá-la
 
-Se você quer a versão curta: o renderer do Koharu é cuidadoso porque a renderização de texto é um problema de sistemas acoplados, não uma etapa final de pintura.
+Se você quer a versão curta: o renderizador do Koharu é cuidadoso porque a renderização de texto é um problema de sistemas acoplados, não uma etapa final de pintura.
 

docs/pt-BR/how-to/troubleshooting.md

@@ -8,7 +8,7 @@ Esta página cobre os problemas mais comuns do Koharu na implementação atual:
 
 ## Antes de começar
 
-Ao fazer troubleshooting, identifique primeiro qual camada está falhando:
+Ao fazer diagnóstico de problemas, identifique primeiro qual camada está falhando:
 
 - inicialização da aplicação
 - downloads de runtime ou modelos
@@ -116,7 +116,7 @@ Use esta ordem:
 
 Se o export falhar porque não há camada renderizada ou inpainted, rode novamente o estágio que está faltando em vez de tentar exportar repetidamente.
 
-## Qualidade de detection ou OCR ruim em uma página
+## Qualidade de detecção ou OCR ruim em uma página
 
 Causas comuns:
 
@@ -124,7 +124,7 @@ Causas comuns:
 - recortes de página incomuns
 - tramas pesadas ou scans ruidosos
 - texto vertical misturado com arte difícil
-- blocos de texto mal colocados ou duplicados após o detection
+- blocos de texto mal colocados ou duplicados após a detecção
 
 Tente isto:
 
@@ -275,4 +275,4 @@ Nesse ponto, colete:
 - [Configurar Clientes MCP](configure-mcp-clients.md)
 - [Build a Partir do Código-Fonte](build-from-source.md)
 - [Referência da CLI](../reference/cli.md)
-- [Technical Deep Dive](../explanation/technical-deep-dive.md)
+- [Mergulho Técnico Profundo](../explanation/technical-deep-dive.md)

docs/pt-BR/how-to/use-openai-compatible-api.md

@@ -136,4 +136,4 @@ Isso permite manter múltiplos backends compatíveis configurados e alternar ent
 
 - [Modelos e Providers](../explanation/models-and-providers.md)
 - [Traduza Sua Primeira Página](../tutorials/translate-your-first-page.md)
-- [Troubleshooting](troubleshooting.md)
+- [Solução de problemas](troubleshooting.md)