globalize is now on the Nimdzi Language Technology Radar

Nimdzi has vetted globalize.now and listed it on its Language Technology Radar, the analyst firm's catalogue of language technology products. globalize.now is AI-powered localization infrastructure, and Nimdzi files it in two places, under localization for developers and under localization-specific LLM tools. This post covers what the Radar is, where globalize sits on it, and why code-native localization has become a category of its own.

What is the Nimdzi Language Technology Radar?

The Radar is a live database of language technology, maintained by Nimdzi Insights. It replaced the older Language Technology Atlas, which was a yearly market snapshot, with a catalogue that is updated continuously. The 2026 edition reports more than 1,100 products from 756 companies.

Products are grouped into eleven categories, from translation management systems and machine translation to speech recognition and interpreting systems. Several categories have subcategories, and a product appears where its core offering fits, not wherever one of its features could stretch.

How does a tool get vetted?

A company submits its data, and Nimdzi's researchers verify it against public information, briefings with the provider and their own use of the tools. Inclusion is free. Nimdzi states that it accepts no commissions to influence listings, rankings or reviews, which is the reason a listing carries weight with buyers.

For globalize that meant a round of questions from the Radar team before the profile was marked complete. Which models and engines translation runs on. Whether quality checks work outside the platform. How corrections carry over to future translations. The categories reflect those answers, not a self-description.

Where does globalize sit on the Radar?

globalize appears in two categories.

Translation Management Systems, localization for developers. This subcategory covers tools built for engineering teams rather than translator teams. The difference is where the work happens. A classic TMS is a separate workspace that strings are synced into and out of. globalize works in the repository, so the output is a pull request with locale files, not an export from a dashboard.

Large Language Models, localization-specific LLM tools. globalize uses language models for translation and for a second review pass that checks meaning, placeholders, glossary terms and style guide fit in every language. The category is for tools where the model is applied to localization work specifically, not general-purpose chat.

You can read the profile on Nimdzi's site.

Why is localization for developers its own category?

Because the people shipping the strings changed. A few years ago, a product team handed copy to a localization manager, who ran it through a TMS and handed files back. Today a solo founder ships a Next.js app built with Cursor or Lovable on a Tuesday and wants it in Japanese by Friday. There is no localization manager, and nobody wants another dashboard to keep in sync.

That shift creates a different job to be done.

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

The developer-side job has two parts. First, the codebase has to be ready for localization at all, which AI-generated apps usually are not. They ship with hardcoded strings in components, no keys and no locale files. globalize handles that once, in the app, when you connect the repository. Second, every later change needs translating without anyone remembering to do it. After setup, each push with new or changed text comes back as a pull request with the translations, reviewed by the AI pass and ready to merge.

Is globalize a TMS, then?

No, even though Nimdzi files the developer subcategory under its TMS heading. globalize sits between your i18n library and your translation engine. Libraries such as next-intl and i18next serve translations at runtime, and globalize keeps working with whichever one you already use. Translation management systems such as Lokalise and Crowdin manage translator workflows. globalize produces and maintains the keys and locale files, so a team without translators does not need that workflow layer at all. If you are comparing the two approaches, the Lokalise comparison goes through the differences.

What does globalize actually do in a repository?

It connects to GitHub or GitLab, scans the repository, and sets up i18n if the app needs it, pushing the change to a branch for you to review. If the app already uses next-intl, react-i18next, i18next or Lingui, it keeps that setup and only translates.

From then on, three things trigger a translation job, all of them settings you control.

1. A push with new or changed text to a watched branch.
2. A pull request, if you turn that option on.
3. A manual job from the dashboard.

Each job translates only what is new or changed. Strings already in translation memory are reused and not billed again. Your glossary and per-language style guides apply to every job, and the review pass flags anything that needs a human before it reaches your default branch. The result lands as a pull request that touches only your locale files.

The formats cover web and mobile, including JSON, gettext PO, XLIFF, YAML, Flutter ARB, Apple string catalogs and Android string resources. Pricing is per workspace with no seat fees, and the pricing page has the current plans.

Why does an analyst listing matter if you are a developer?

For most developers it does not change much. You will judge globalize by the first pull request, and the free trial is there for exactly that. The listing matters to two other groups.

The first is teams with a localization lead. A localization manager evaluating tools reads Nimdzi, and an independent vetted profile tells them the product exists, works as described, and sits in a category they recognize. That is a shorter conversation than a cold demo.

The second is buyers moving off a classic TMS. Teams leaving Lokalise or Phrase for a code-native setup want to know the alternative is real before they move a production catalog. A Radar listing is one of the few signals in this market that the vendor cannot write about itself.

What comes next?

Nimdzi also runs a TMS Feature Explorer, a feature-by-feature profile for each tool, and the globalize entry is in progress. When it goes live it will show, item by item, what globalize covers and where it deliberately does not, such as translator editors and vendor management, which are outside what a code-native tool is for.

In the meantime, the fastest way to judge it is on your own code. Connect a repository, let globalize run the setup, and read the first translated pull request.