Lokali — Translation Hub

A gestão das traduções da S2therapy dependia diretamente do processo de desenvolvimento.

Quando um texto precisava ser alterado, a solicitação era adicionada ao Trello com o conteúdo e a tradução pretendida. Depois, eu precisava localizar manualmente a key correspondente nos ficheiros, alterar diferentes arquivos e preparar a mudança no código.

O problema tornou-se maior com Web, Android e iOS. Cada plataforma utilizava estruturas próprias e nem sempre as mesmas keys representavam os mesmos conteúdos.

Como resultado, além de pequenas alterações de conteúdo criarem demanda de desenvolvimento, começaram a surgir inconsistências: Android podia apresentar um texto, iOS outro e Web um terceiro para o mesmo conceito.

A internacionalização do produto cresceu juntamente com a S2therapy. Diferentes aplicações passaram a manter milhares de keys distribuídas por múltiplos ficheiros e locales.

O dashboard da plataforma atualmente indexa 4.217 keys, 19 ficheiros e 13 locales. Parte dessa estrutura ainda inclui projetos Android e iOS legados, que estão a ser consolidados após a migração da aplicação mobile para Flutter.

O processo baseado em Trello não escalava bem porque separava quem conhecia o conteúdo de quem tinha permissão e conhecimento técnico para alterá-lo.

A oportunidade era transformar localização num processo self-service, sem perder o controlo técnico proporcionado pelo GitHub.

Fui responsável por todo o projeto, atuando na definição do produto, UX, regras de negócio e desenvolvimento Full Stack assistido por IA.

Identifiquei o problema a partir do nosso próprio processo interno, defini o workflow de localização, modelei uma representação comum para diferentes formatos de tradução e desenvolvi as funcionalidades de integração com GitHub, comparação, glossário e assistência por IA.

Utilizei Lovable como acelerador de desenvolvimento, com React e Supabase como base da aplicação.

O Lokali transforma ficheiros de tradução mantidos no código numa experiência de gestão de conteúdo acessível a utilizadores não técnicos.

Um utilizador cria um projeto, conecta um repositório GitHub, seleciona uma branch e indica quais ficheiros correspondem a cada locale. A plataforma importa e normaliza os conteúdos, permitindo gerir diferentes formatos através de uma interface comum.

Depois da edição, as alterações voltam ao processo normal de engenharia: a plataforma realiza o commit e abre um Pull Request no GitHub, preservando revisão e rastreabilidade.

A plataforma inclui ainda:

• Glossário, para definir terminologia preferencial e manter consistência;
• Sugestões com IA, considerando os valores existentes e o glossário antes de propor uma tradução;
• Comparador, para identificar diferenças entre traduções das aplicações;
• Sincronização manual com GitHub, permitindo atualizar a plataforma quando o código muda externamente.

A IA apenas sugere conteúdo. A decisão final continua sempre com uma pessoa.

O projeto nasceu de uma necessidade interna, e o próprio processo anterior serviu como ponto de partida para definir o produto.

O fluxo original era: Solicitação no Trello → localizar key → encontrar ficheiros → alterar traduções → commit O objetivo foi eliminar as etapas técnicas para quem precisava apenas gerir conteúdo, sem criar um sistema paralelo ao GitHub.

A primeira versão funcional foi desenvolvida em aproximadamente um mês, utilizando Lovable para acelerar a implementação. Durante o desenvolvimento, os diferentes formatos de localização foram transformados num modelo comum de keys, valores e locales, permitindo que Android XML, iOS Strings e JSON fossem apresentados através da mesma experiência.

O produto foi então utilizado internamente na própria S2therapy, permitindo evoluir as funcionalidades a partir de um problema real e do uso diário.

A decisão mais importante foi não substituir o GitHub como fonte de verdade.

Em vez de criar uma base de traduções completamente independente do código, o Lokali funciona como uma camada de gestão sobre o workflow existente. As alterações continuam a regressar aos repositórios através de commits e Pull Requests.

Outra decisão foi normalizar diferentes formatos de localização num modelo comum. Isso permitiu esconder detalhes técnicos de Android, iOS e Web sem exigir que todas as aplicações adotassem imediatamente o mesmo formato.

Para IA, optei por um modelo human-in-the-loop. As sugestões utilizam contexto existente e glossário para melhorar consistência, mas nunca são aplicadas automaticamente.

Também optei por construir uma ferramenta interna em vez de contratar uma plataforma comercial de localização. As soluções existentes adicionavam custo e não ofereciam exatamente o workflow e as funcionalidades específicas que pretendíamos, enquanto já tínhamos Lovable disponível para acelerar uma solução própria.

A plataforma utiliza React no frontend e Supabase para autenticação, persistência e serviços de backend.

A integração com GitHub conecta os projetos de tradução aos respetivos repositórios e branches. Os ficheiros são importados e transformados numa representação comum de keys, locales e valores.

Atualmente são suportadas estruturas como JSON para Web, Android XML e ficheiros de strings do iOS, embora Android e iOS sejam agora considerados fontes legadas após a consolidação da aplicação mobile em Flutter.

A camada de IA utiliza os recursos disponibilizados através do Lovable e consulta também o glossário antes de produzir sugestões.

┌──────────────┐ │ GitHub │ │ Repositories │ └──────┬───────┘ │ Import / Sync │ ┌────────▼────────┐ │ Lokali │ │ React + Supabase│ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ Translations Glossary Comparator │ │ │ └────────────┼────────────┘ │ AI Suggestions │ Human Review │ Commit + Pull Request │ ┌─────▼─────┐ │ GitHub │ └───────────┘

O principal desafio técnico foi integrar a gestão de conteúdo com GitHub sem criar uma segunda fonte de verdade.

A ferramenta precisava permitir que uma pessoa não técnica alterasse traduções enquanto mantinha os mecanismos utilizados pela equipa de engenharia: branches, commits e Pull Requests.

Outro desafio foi lidar com diferentes estruturas de localização e apresentá-las através de uma experiência comum.

A consistência entre plataformas trouxe um problema adicional. Como aplicações diferentes nem sempre utilizavam as mesmas keys, identificar conceitos equivalentes tornou-se uma necessidade importante. O comparador nasceu para tornar essas diferenças visíveis e facilitar a harmonização da linguagem entre os produtos.

A integração com GitHub continua sendo uma área de evolução do projeto, principalmente para tornar sincronização e gestão das alterações ainda mais robustas.

O Lokali transformou um processo baseado em Trello + intervenção manual de desenvolvimento num workflow self-service integrado diretamente ao GitHub.

Solicitações de conteúdo que podiam permanecer até 3 dias no processo anterior deixaram de depender da minha disponibilidade como developer.

Para mim, o ganho também foi significativo: uma alteração que anteriormente podia exigir editar quatro ficheiros diferentes passou a poder ser realizada através de uma única linha numa interface centralizada.

Atualmente a plataforma gere dados reais da S2therapy/Space4.me, com 4.217 keys, 19 ficheiros e 13 locales indexados no ambiente atual, embora parte dos ficheiros represente aplicações mobile legadas que serão removidas após a consolidação em Flutter.

Mais importante que os números, a responsabilidade sobre o conteúdo deixou de estar necessariamente ligada à responsabilidade sobre o código.