A globalize agora está no Nimdzi Language Technology Radar

A Nimdzi avaliou a globalize.now e a incluiu no Language Technology Radar, o catálogo de produtos de tecnologia de idiomas da consultoria. A globalize.now é uma infraestrutura de localização com IA, e a Nimdzi a classifica em dois lugares: localização para desenvolvedores e ferramentas de LLM específicas para localização. Neste post, explicamos o que é o Radar, onde a globalize aparece nele e por que a localização code-native se tornou uma categoria própria.

O que é o Nimdzi Language Technology Radar?

O Radar é um banco de dados vivo de tecnologia de idiomas, mantido pela Nimdzi Insights. Ele substituiu o antigo Language Technology Atlas, que era um retrato anual do mercado, por um catálogo atualizado continuamente. A edição de 2026 reúne mais de 1.100 produtos de 756 empresas.

Os produtos são agrupados em onze categorias, de sistemas de gerenciamento de tradução e tradução automática a reconhecimento de fala e sistemas de interpretação. Várias categorias têm subcategorias, e cada produto aparece onde sua oferta principal se encaixa, e não em qualquer lugar a que uma de suas funcionalidades possa chegar.

Como uma ferramenta é avaliada?

A empresa envia seus dados, e os pesquisadores da Nimdzi os verificam com base em informações públicas, reuniões com o fornecedor e o uso que eles mesmos fazem das ferramentas. A inclusão é gratuita. A Nimdzi declara que não aceita comissões para influenciar listagens, rankings ou avaliações, e é por isso que uma listagem tem peso para quem está comprando.

No caso da globalize, isso significou uma rodada de perguntas da equipe do Radar antes de o perfil ser marcado como completo. Em quais modelos e mecanismos a tradução roda. Se as verificações de qualidade funcionam fora da plataforma. Como as correções são aproveitadas em traduções futuras. As categorias refletem essas respostas, e não uma autodescrição.

Onde a globalize aparece no Radar?

A globalize aparece em duas categorias.

Translation Management Systems, localização para desenvolvedores. Esta subcategoria reúne ferramentas feitas para equipes de engenharia, e não para equipes de tradutores. A diferença está em onde o trabalho acontece. Um TMS clássico é um ambiente separado, para onde as strings são sincronizadas e de onde saem. A globalize trabalha no repositório, então o resultado é um pull request com arquivos de locale, e não uma exportação feita a partir de um dashboard.

Large Language Models, ferramentas de LLM específicas para localização. A globalize usa modelos de linguagem para traduzir e para uma segunda etapa de revisão que verifica sentido, placeholders, termos do glossário e aderência ao guia de estilo em cada idioma. A categoria é voltada a ferramentas em que o modelo é aplicado especificamente ao trabalho de localização, e não a um chat de uso geral.

Você pode ver o perfil no site da Nimdzi.

Por que localização para desenvolvedores é uma categoria própria?

Porque mudou quem entrega as strings. Alguns anos atrás, uma equipe de produto passava o texto para um gerente de localização, que o processava em um TMS e devolvia os arquivos. Hoje, um fundador solo publica numa terça-feira um app em Next.js criado com Cursor ou Lovable e quer ele em japonês até sexta. Não existe gerente de localização, e ninguém quer mais um dashboard para manter sincronizado.

Essa mudança cria uma necessidade diferente a ser atendida (o chamado "job to be done").

classic TMS:  code  →  export strings  →  TMS workspace  →  translators  →  import files  →  code
globalize:    code  →  push  →  translated pull request  →  merge

O trabalho do lado do desenvolvedor tem duas partes. Primeiro, a base de código precisa estar preparada para localização, o que apps gerados por IA geralmente não estão. Eles saem com strings hardcoded nos componentes, sem chaves e sem arquivos de locale. A globalize resolve isso uma única vez, dentro do app, quando você conecta o repositório. Segundo, toda alteração posterior precisa ser traduzida sem que ninguém precise lembrar de fazer isso. Depois da configuração, cada push com texto novo ou alterado volta como um pull request com as traduções, já revisadas pela etapa de IA e prontas para o merge.

Então a globalize é um TMS?

Não, embora a Nimdzi classifique a subcategoria para desenvolvedores dentro de TMS. A globalize fica entre a sua biblioteca de i18n e o seu mecanismo de tradução. Bibliotecas como next-intl e i18next entregam as traduções em tempo de execução, e a globalize continua funcionando com a que você já usa. Sistemas de gerenciamento de tradução, como Lokalise e Crowdin, gerenciam fluxos de trabalho de tradutores. A globalize gera e mantém as chaves e os arquivos de locale, então uma equipe sem tradutores não precisa dessa camada de fluxo de trabalho. Se você está comparando as duas abordagens, a comparação com o Lokalise detalha as diferenças.

O que a globalize realmente faz em um repositório?

Ela se conecta ao GitHub ou GitLab, analisa o repositório e configura o i18n se o app precisar, enviando a alteração para uma branch para você revisar. Se o app já usa next-intl, react-i18next, i18next ou Lingui, ela mantém essa configuração e só traduz.

A partir daí, três eventos disparam um job de tradução, todos configuráveis por você.

1. Um push com texto novo ou alterado em uma branch monitorada.
2. Um pull request, se você ativar essa opção.
3. Um job manual, disparado pelo dashboard.

Cada job traduz apenas o que é novo ou foi alterado. Strings que já estão na memória de tradução são reaproveitadas e não são cobradas de novo. Seu glossário e os guias de estilo por idioma valem para todos os jobs, e a etapa de revisão sinaliza tudo o que precisa de uma pessoa antes de chegar à sua branch padrão. O resultado chega como um pull request que mexe apenas nos seus arquivos de locale.

Os formatos cobrem web e mobile, incluindo JSON, gettext PO, XLIFF, YAML, Flutter ARB, catálogos de strings da Apple e recursos de strings do Android. O preço é por workspace, sem cobrança por usuário, e a página de preços traz os planos atuais.

Por que uma listagem de analistas importa para quem é desenvolvedor?

Para a maioria dos desenvolvedores, não muda muita coisa. Você vai avaliar a globalize pelo primeiro pull request, e o teste gratuito existe justamente para isso. A listagem importa para dois outros grupos.

O primeiro são as equipes que têm um responsável por localização. Um gerente de localização que avalia ferramentas lê a Nimdzi, e um perfil independente e avaliado mostra a ele que o produto existe, funciona como descrito e está em uma categoria que ele reconhece. Isso torna a conversa mais curta do que uma demo a frio.

O segundo são compradores que estão saindo de um TMS clássico. Equipes que deixam o Lokalise ou a Phrase por uma solução code-native querem saber se a alternativa é real antes de migrar um catálogo em produção. Uma listagem no Radar é um dos poucos sinais nesse mercado que o próprio fornecedor não consegue escrever sobre si mesmo.

Quais são os próximos passos?

A Nimdzi também mantém o TMS Feature Explorer, um perfil funcionalidade por funcionalidade de cada ferramenta, e a entrada da globalize está em andamento. Quando for ao ar, ela mostrará, item por item, o que a globalize cobre e o que ela deliberadamente não cobre, como editores para tradutores e gestão de fornecedores, que estão fora do propósito de uma ferramenta code-native.

Enquanto isso, a forma mais rápida de avaliar é testar no seu próprio código. Conecte um repositório, deixe a globalize fazer a configuração e leia o primeiro pull request traduzido.