DEV Community: Eray Gündoğmuş

Build a Multilingual Next.js App in 5 Minutes with App Router

Eray Gündoğmuş — Mon, 02 Mar 2026 22:21:56 +0000

TL;DR

A production-ready Next.js 15 + App Router i18n starter template with server-side translations, instant locale switching, and 15 languages out of the box.

GitHub Repo | Live Demo

What You Get

⚡ Next.js 15 with App Router and Server Components
🌍 15 languages pre-configured (EN, TR, DE, ES, FR, JA, KO, ZH, AR, RU, IT, NL, HI, PL, PT)
🔄 Instant locale switching — no full page reload
🖥️ SSR translations — no flash of untranslated content
📦 Cloud-managed translations via better-i18n CDN
🎨 Tailwind CSS 4 + shadcn/ui components
🔍 SEO-ready — hreflang tags, Open Graph, JSON-LD schemas, sitemap

Quick Start

Step 1: Clone and install

npx create-next-app -e https://github.com/better-i18n/nextjs-i18n-starter my-i18n-app
cd my-i18n-app

Step 2: Create a free project at dash.better-i18n.com, add your languages, and set the env variable:

echo 'NEXT_PUBLIC_BETTER_I18N_PROJECT=your-org/your-project' > .env

Step 3: Run it

npm run dev
# Open http://localhost:3000

Done. You have a multilingual Next.js app.

How It Works

The entire setup is 3 files:

Config (`i18n.config.ts`)

import { createI18n } from "@better-i18n/next";

export const i18n = createI18n({
  project: process.env.NEXT_PUBLIC_BETTER_I18N_PROJECT || "better-i18n/demo",
  defaultLocale: "en",
  localePrefix: "always",
});

Middleware (`middleware.ts`)

import { i18n } from "./i18n.config";

export default i18n.betterMiddleware();

Yes, that's it. One line handles locale detection, redirects, and path prefixing.

Layout (`src/app/[locale]/layout.tsx`)

export default async function LocaleLayout({ children, params }) {
  const { locale } = await params;
  const messages = await i18n.getMessages(locale);

  return (
    <html lang={locale}>
      <body>
        <BetterI18nProvider config={i18n.config} locale={locale} messages={messages}>
          {children}
        </BetterI18nProvider>
      </body>
    </html>
  );
}

Translations load server-side from CDN → passed to provider → available everywhere via useTranslations().

Customization

Add a new language

Just add it in the better-i18n dashboard. The useManifestLanguages hook in the language switcher picks it up automatically — no code changes needed.

Add a new page

// src/app/[locale]/pricing/page.tsx
import { useTranslations } from "next-intl";

export default function PricingPage() {
  const t = useTranslations("pricing");
  return <h1>{t("title")}</h1>;
}

Add your translation keys in the dashboard, and the page works in all languages.

Deploy to Vercel

npm run build
# Or push to GitHub and connect to Vercel for automatic deploys

The starter works out of the box on Vercel with zero configuration.

Links

If this is useful, drop a ⭐ on the repo!

Best i18n Libraries for Next.js, React & React Native in 2026 (Honest Comparison)

Eray Gündoğmuş — Mon, 02 Mar 2026 15:30:25 +0000

If you're building a multilingual app in 2026, the i18n landscape has never been more competitive — or more confusing. The Next.js App Router killed the old routing-based i18n approach, React Server Components changed how translations load, and AI-powered workflows are reshaping the entire localization pipeline.

We reviewed 12 libraries and platforms across five dimensions: developer experience, type safety, performance, ecosystem maturity, and scalability. This guide helps you pick the right tool — whether you're a solo developer or an enterprise team shipping to 40+ locales.

Transparency note: We built Better i18n, so we list it first and know it best. But this comparison is honest — we include real limitations and tell you when a competitor is the better choice for your use case.

TL;DR — Quick Comparison Table

Library	React	Next.js App Router	React Native	TypeScript	Bundle Size	Best For
Better i18n	✅	✅	✅ (Expo)	✅ (full)	~2KB SDK	AI translations + CDN delivery + DX
next-intl	❌	✅	❌	✅	457B	Next.js-only projects, quick setup
react-i18next	✅	✅	✅	✅	~6KB	Large teams with existing i18next knowledge
LinguiJS	✅	✅	✅	✅	~2KB	Compile-time safety, minimal bundles
Paraglide	✅	✅	❌	✅ (full)	Tree-shaken	Translated URLs, type-safe DX
FormatJS (react-intl)	✅	✅	✅	✅	~20KB	Complex ICU message formatting
next-translate	❌	✅ (Pages)	❌	Partial	498B	Legacy Next.js Pages Router projects
Intlayer	✅	✅	❌	✅	~8KB	Enterprise SEO + component-scoped i18n
typesafe-i18n	✅	✅	✅	✅ (full)	~1KB	Maximum type safety, zero deps
zero-intl	✅	❌	❌	✅	~15KB	Lightweight modern React apps

How We Evaluated

We scored each library across five dimensions:

Developer Experience (DX) — Setup time, API ergonomics, documentation quality
Type Safety — Autocomplete on keys, compile-time checks, TypeScript depth
Performance — Bundle size, tree-shaking, runtime overhead, CDN delivery
Ecosystem & Maturity — Community size, maintenance frequency, plugin ecosystem
Scalability — How well it handles 50+ locales, 10K+ keys, large teams

1. Better i18n

What it is: A full localization platform with type-safe SDKs, AI-powered translations, git-native workflow, and instant CDN delivery.

Why it's different: Most libraries on this list handle only the client-side rendering of translations. Better i18n covers the entire pipeline — from key discovery in your codebase to AI translation to CDN delivery — so you never manually export/import JSON files.

Key Features

AI-powered, brand-aware translations — Not generic machine translation. Uses your glossary, brand voice, and product context.
AST-based key discovery — Scans your codebase and finds translation keys automatically. No manual extraction.
Git-native sync — Translations come as automatic PRs to your repository. No manual file management.
Instant CDN delivery — Sub-50ms from Cloudflare's edge. No build step needed for translation updates.
MCP integration — Manage translations directly from Claude or Cursor. (No other platform offers this.)
11 framework SDKs — React, Next.js, Vue, Angular, Svelte, Nuxt, Remix, Astro, TanStack Start, Vite, Expo.

Code Example (Next.js App Router)

// app/[locale]/page.tsx
import { useTranslations } from "@better-i18n/react";

export default function HomePage() {
  const t = useTranslations();

  return (
    <main>
      <h1>{t("hero.title")}</h1>
      <p>{t("hero.subtitle")}</p>
    </main>
  );
}

Keys are fully typed — you get autocomplete and compile-time errors for missing keys.

When to Choose Better i18n

✅ You want AI translations that understand your product context
✅ You need instant CDN delivery without build steps
✅ You're tired of manually managing JSON translation files
✅ You want one platform for React, Next.js, Vue, and more
✅ You work with AI tools (Claude, Cursor) and want MCP integration

When NOT to Choose Better i18n

❌ You need a zero-dependency, client-only library with no external service
❌ You already have a well-established i18next pipeline
❌ You want a library with 5+ years of community battle-testing
❌ Your project has zero budget (the free tier covers 1K keys / 2 languages)

Pricing

Free: 1,000 keys, 2 languages, CDN delivery
Pro: $19/mo — unlimited everything, AI translations, git sync
Enterprise: Custom — SSO, SLA, on-premise

2. next-intl

What it is: The most popular i18n library built specifically for Next.js App Router.

next-intl has become the go-to choice for Next.js developers who want a quick, reliable setup. It integrates through a Next.js plugin, provides useTranslations hooks, locale-aware routing via middleware, and JSON-based dictionaries.

Code Example

import { useTranslations } from "next-intl";

export default function About() {
  const t = useTranslations("about");
  return <h1>{t("title")}</h1>;
}

Strengths

Extremely fast setup (minutes, not hours)
First-class Next.js App Router support with Server Components
Active maintenance, strong community
Lightweight (457B gzipped)

Limitations

Next.js only — no React Native, no Vue, no standalone React
You manage translation files yourself (no TMS included)
No AI translation or CDN delivery built in

When to Choose

You're building a Next.js-only project, want zero overhead, and are happy managing JSON files by hand.

3. react-i18next

What it is: The most battle-tested i18n library in the React ecosystem, backed by the i18next framework.

If your team already knows i18next, this is the safest bet. It supports namespaces, lazy loading, interpolation, pluralization, and virtually every pattern you can think of. The community is massive.

Code Example

import { useTranslation } from "react-i18next";

function MyComponent() {
  const { t } = useTranslation();
  return <p>{t("welcome_message", { name: "World" })}</p>;
}

Strengths

Largest community and most plugins in the ecosystem
Works everywhere: React, React Native, Next.js, Node.js
Battle-tested at enterprise scale
Extensive documentation and examples

Limitations

More boilerplate than newer alternatives
Server-side rendering requires careful configuration
No built-in type safety for keys (needs extra setup)
Bundle size is larger (~6KB)

When to Choose

Your team already knows i18next, or you need maximum flexibility and plugin ecosystem.

4. LinguiJS

What it is: A compile-time i18n library that extracts messages at build time and produces minimal bundles.

LinguiJS takes a fundamentally different approach. Instead of loading JSON files at runtime, it compiles translations at build time. You write messages using macros directly in your components, then run extraction and compilation steps.

Code Example

import { Trans } from "@lingui/macro";

function Welcome({ name }) {
  return <Trans>Hello {name}, welcome back!</Trans>;
}

Strengths

Smallest possible runtime bundle (~2KB)
Build-time checks catch missing translations
ICU message format support
Tree-shaking: only ships messages actually used

Limitations

Requires Babel/SWC plugin configuration
Build-time extraction adds complexity to CI/CD
Steeper learning curve for macro-based API
Smaller community than react-i18next

When to Choose

Performance is critical, your team is comfortable with build tooling, and you want compile-time guarantees.

5. Paraglide (by Inlang)

What it is: A modern, fully type-safe i18n library with tree-shakeable messages and translated URL pathnames.

Paraglide generates type-safe functions from your messages, so every translation key is a function call with full autocomplete. It also supports translated pathnames — your URLs can be /en/about and /de/ueber-uns natively.

Strengths

Full type safety with generated message functions
Tree-shakeable: zero unused translations in bundle
Translated pathnames for localized URLs
GUI editor for translators (via Inlang ecosystem)

Limitations

Younger ecosystem, fewer production case studies
No React Native support
Requires code generation step
Smaller community

When to Choose

You prioritize type safety and localized URLs, and you're building for web only.

6. FormatJS (react-intl)

What it is: A comprehensive i18n framework with full ICU message format support.

FormatJS is the gold standard for complex message formatting — plurals, select statements, gender variations, and rich text. If your content has phrases like "You have {count, plural, one {# item} other {# items}} in your cart," FormatJS handles it natively.

Strengths

Most complete ICU message format implementation
Handles complex pluralization and gender rules
Works across React, React Native, and Node.js
Backed by a large, long-standing community

Limitations

Largest bundle size (~20KB gzipped)
Verbose API compared to newer libraries
Setup is heavier than lightweight alternatives

When to Choose

Your app has complex linguistic requirements (multiple pluralization rules, gender-dependent messages, rich text interpolation).

7. Intlayer

What it is: An opinionated, enterprise-focused i18n solution with component-scoped translations and built-in SEO helpers.

Strengths

Component-scoped translation declarations
Built-in SEO helpers (hreflang, meta tags)
Strict TypeScript types with build-time validation
Missing key detection at build time

Limitations

Heavier and more opinionated than alternatives
Smaller community
Steeper learning curve

When to Choose

Enterprise projects that need SEO integration and strict build-time validation.

8. typesafe-i18n

What it is: A zero-dependency, fully type-safe i18n library with code generation.

Strengths

Smallest runtime (~1KB + generated code)
Full type safety with autocomplete
Zero external dependencies
Works with React, Svelte, Vue, Vanilla JS

Limitations

Last major update in 2023
Requires code generation
Custom message format (not standard ICU)

When to Choose

You want absolute minimal bundle size and full type safety in a smaller project.

Decision Framework

Still not sure? Here's a flowchart:

Do you need a full platform (TMS + CDN + AI)?
  ├── Yes → Better i18n
  └── No → Continue...

Are you using Next.js App Router only?
  ├── Yes → next-intl (fastest setup)
  └── No → Continue...

Do you need React Native support?
  ├── Yes → react-i18next or Better i18n
  └── No → Continue...

Is bundle size your #1 priority?
  ├── Yes → LinguiJS or typesafe-i18n
  └── No → Continue...

Do you need complex ICU formatting?
  ├── Yes → FormatJS (react-intl)
  └── No → Continue...

Do you want type-safe translated URLs?
  ├── Yes → Paraglide
  └── No → react-i18next (safest default)

Performance Benchmarks

Library	Bundle Size (gzip)	Runtime Overhead	Cold Start Impact
Better i18n SDK	~2KB	Minimal (CDN fetch)	Low
next-intl	457B	Minimal	Very Low
react-i18next	~6KB	Low	Low
LinguiJS	~2KB	Near-zero (compiled)	Very Low
Paraglide	Tree-shaken	Near-zero	Very Low
FormatJS	~20KB	Medium	Medium
typesafe-i18n	~1KB	Minimal	Very Low

The Takeaway

There's no single "best" i18n library — only the best one for your context. Here's our honest ranking by use case:

Best all-in-one platform: Better i18n — if you want AI translations, CDN delivery, and git sync without stitching together multiple tools.
Best for Next.js simplicity: next-intl — drop it in and go.
Best for large existing teams: react-i18next — community knowledge and plugin ecosystem are unmatched.
Best for performance purists: LinguiJS — compile-time guarantees and minimal bundles.
Best for type-safe DX: Paraglide — every key is a typed function.
Best for complex messages: FormatJS — full ICU power.

Whatever you choose, pick a tool that grows with your project. Migrating i18n libraries mid-project is one of the most painful refactors in frontend development. Measure twice, ship once.

Scaling i18n Beyond Lazy Loading: What Framework Comparisons Miss About Real-World Localization

Eray Gündoğmuş — Sun, 01 Mar 2026 15:02:55 +0000

I've read a lot of "how we scaled our i18n" posts. They almost all follow the same arc: team evaluates frameworks, picks i18next or FormatJS, implements lazy loading per namespace, ships it, writes the blog post. Bundle size goes down, page load improves, everyone's happy.

I know because we wrote that exact post internally 18 months ago. Then we spent the next 12 months dealing with everything the framework comparison didn't cover.

This post is about those 12 months. Not the framework choice — the infrastructure, workflow, and operational problems that show up at scale but never make it into the comparison table.

The framework comparison trap

Most i18n framework evaluations look something like this:

Criteria	i18next	FormatJS	Polyglot
Bundle size (core)	~40KB	~32KB	~3KB
Lazy loading	Plugin-based	Built-in	Manual
ICU support	Plugin	Native	None
React integration	react-i18next	react-intl	Manual
TypeScript	Good	Good	Weak
Community	Large	Large	Small

This is accurate and useful for picking a library. It is almost entirely useless for predicting what your localization workflow will look like at 500+ keys, 6+ languages, and a team of 8+ developers shipping weekly.

Here's what the comparison table doesn't tell you:

How will you detect unused translation keys after a refactor?
What happens when two feature branches modify the same locale file?
How long does it take to push a one-word translation fix to production?
How will your translators get context about what they're translating?
Who maintains the mapping between translation keys and the codebase?

These are the problems that actually consume engineering time. The framework is a pipe fitting. The plumbing is everything else.

Problem 1: The namespace illusion

Namespace splitting is the first optimization every team implements. Instead of one massive translation.json, you split into auth.json, dashboard.json, settings.json, etc.

// i18next namespace config
i18n.init({
  ns: ['common', 'auth', 'dashboard', 'settings', 'billing'],
  defaultNS: 'common',
  backend: {
    loadPath: '/locales/{{lng}}/{{ns}}.json',
  },
});

With lazy loading, each namespace loads on demand:

// Only loads 'dashboard' namespace when this route mounts
const DashboardPage = () => {
  const { t } = useTranslation('dashboard');
  return <h1>{t('title')}</h1>;
};

Bundle problem: solved. Performance: improved. Blog post: written.

But here's what happens next.

The namespace decision tax

Developer writes a new error component for the billing page. Where does billing.errors.cardDeclined go? In billing.json or errors.json? If you have both namespaces, now you have a naming convention meeting. If you decide it goes in billing.json, what happens when the same error also shows on the settings page where users update their payment method?

We tracked this over 4 sprints. Developers spent an average of 7 minutes per new key deciding which namespace it belonged to. With 15-20 new keys per sprint, that's 2+ hours of namespace deliberation per sprint across the team. And that's before the reviewer disagrees and asks for a rename.

The cross-namespace import problem

Components that span multiple features need multiple namespaces:

// A notification component that shows messages from different domains
const NotificationItem = ({ notification }) => {
  const { t: tBilling } = useTranslation('billing');
  const { t: tAuth } = useTranslation('auth');
  const { t: tDashboard } = useTranslation('dashboard');

  const getMessage = () => {
    switch (notification.domain) {
      case 'billing': return tBilling(`notifications.${notification.key}`);
      case 'auth': return tAuth(`notifications.${notification.key}`);
      case 'dashboard': return tDashboard(`notifications.${notification.key}`);
    }
  };

  return <p>{getMessage()}</p>;
};

This defeats the purpose of lazy loading. You're now loading 3 namespaces for a single component. Worse, you've created implicit coupling between namespaces and feature boundaries that breaks every time someone moves a component.

What actually works

Flat keys with convention-based prefixes, no namespace boundaries:

// No namespaces. One flat map. Convention handles organization.
const t = useTranslations('billing');
t('errors.cardDeclined');     // → "billing.errors.cardDeclined"
t('notifications.overdue');   // → "billing.notifications.overdue"

The namespace is a logical prefix, not a file boundary. No files to split. No lazy loading configuration per namespace. The entire locale payload is edge-cached on a CDN and delivered in a single request.

"But won't that be slow?" At 1,000 keys, a gzipped JSON payload is ~18KB. That's smaller than most hero images. At 5,000 keys, it's ~70KB. A single CDN request at ~2ms from the nearest PoP beats the waterfall of 8 namespace requests at ~40ms each, every time.

Problem 2: The merge conflict multiplier

If your translations live as JSON files in the repo, every feature branch that adds a key modifies the same file. With a team of 6 developers, you're touching en.json in every sprint, often in every PR.

Git's diff algorithm treats JSON as text. A single reordered key produces a multi-line diff. Two developers adding keys in the same file — even in different sections — produces a merge conflict because JSON doesn't have a natural merge strategy.

// Developer A adds key at line 847
"billing.newPlan.title": "Choose your plan",

// Developer B adds key at line 848
"billing.upgrade.cta": "Upgrade now",

// Git: CONFLICT

Namespace splitting reduces conflict frequency but doesn't eliminate it. With 5 namespaces and 6 developers, you still get 1-2 conflicts per sprint. Each conflict requires someone to manually resolve a JSON file, re-validate the JSON syntax, and re-run the translation CI check.

What actually works

Remove JSON files from the repo entirely.

// Translations fetched from CDN at request time
import { getMessages } from '@better-i18n/use-intl/server';

export default async function Layout({ children, params: { locale } }) {
  const messages = await getMessages({
    project: 'my-app',
    locale,
  });

  return (
    <IntlProvider locale={locale} messages={messages}>
      {children}
    </IntlProvider>
  );
}

No locales/ directory in the repo. No JSON files to conflict. Keys are managed on a platform and served via CDN. If you want a Git record, the platform creates archive PRs — but they're documentation, not source of truth.

The Git PR flow inverts:

Before:  Code → JSON files → TMS → JSON files → Merge conflicts
After:   Code → Platform → CDN (live) + Git PR (archive)

Problem 3: The ghost key problem

After 6 months of active development, we had 2,400 translation keys. After running a dead code analysis, 340 of them (14%) weren't referenced anywhere in the codebase.

These ghost keys accumulated over multiple refactors. When you rename a component from <OnboardingWizard> to <SetupFlow>, the code changes but nobody remembers to delete onboarding.wizard.step1.title from the JSON file. Why? Because deleting a key feels risky. What if it's used somewhere you didn't check? What if another component imports it dynamically?

So the keys stay. And your translators translate all of them. At $0.08/word across 6 languages, those 340 ghost keys cost us roughly $1,100 in unnecessary translation work over 6 months. That's before you count the translator time wasted on context questions about strings that don't correspond to any visible UI.

Why regex-based detection fails

The obvious fix is to scan the codebase for key references. Most teams write a script:

# Find keys in JSON that aren't referenced in source
grep -r "onboarding.wizard" src/ --include="*.tsx"

This misses:

Namespaced keys: t('step1.title') inside a component that called useTranslations('onboarding.wizard') — the full key is onboarding.wizard.step1.title, but the source code only has step1.title.
Dynamic keys: t(\error.${code}) — you can't statically resolve the full key.
Passed references: <Child t={t} /> — the key usage is in the child, but the namespace binding is in the parent.

What actually works: AST scanning

Parse the actual syntax tree, not the text:

$ npx @better-i18n/cli scan

Scanning src/ for translation keys...

Found 2,412 keys in project
  ├── 2,072 matched (used in code)
  ├── 340 unused (safe to remove)
  └── 18 dynamic (manual review needed)

Dynamic keys (cannot statically resolve):
  src/components/ErrorBanner.tsx:14  →  t(`error.${code}`)
  src/lib/notifications.ts:28       →  t(`notification.${type}.title`)
  ...

The AST parser:

Finds all useTranslations('namespace') calls and tracks the bound variable
Follows the variable through the component scope
When it sees t('key'), resolves the full qualified key: namespace.key
Cross-references against the platform's key inventory
Flags dynamic keys (template literals, computed values) for manual review

This runs in CI. Every PR gets a check: "This PR removes 3 key references. The following keys will become unused: [list]." No ghost keys accumulate.

Problem 4: The 47-minute typo fix

Your German translator finds that "Weiter" (next) should be "Fortfahren" (continue) on the checkout page. One word.

With file-based i18n, pushing that fix requires:

Open translation file or TMS
Edit the string
If TMS: wait for sync → PR bot → merge → build → deploy
If file-based: edit JSON → commit → push → build → deploy

Either way, a one-word change triggers a full deployment pipeline. CI runs, tests execute, containers build, CDN cache purges. Minimum 5 minutes. Average 15-45 minutes depending on your pipeline.

Now multiply this by 3-5 translation fixes per week. Your deployment pipeline is spending 15-25% of its runs on copy changes that don't touch a single line of application code.

What actually works: CDN-decoupled translations

Translation fix flow:
  1. Edit string in dashboard
  2. Click "Publish"
  3. CDN cache invalidates globally (~2 seconds)
  4. Next user request serves the corrected translation

Time: under 30 seconds. No build. No deploy. No PR.

For the architecture-curious:

Browser → Next.js Server Component
  → getMessages({ project, locale })
    → CDN Edge (cache HIT: ~2ms / MISS: ~40ms)
      → Platform API → Database

The response is a flat JSON object, edge-cached with stale-while-revalidate. Even on cache miss, the server doesn't block — it serves stale content and revalidates in the background.

For SSR/RSC, messages are fetched once in the layout and serialized into the RSC payload. No additional CDN request from the client. Hydration uses the pre-fetched messages.

// Server: one CDN fetch per request
const messages = await getMessages({ project: 'app', locale });

// Client: zero CDN fetches, messages arrive via RSC payload
<IntlProvider locale={locale} messages={messages}>
  {children}
</IntlProvider>

Problem 5: The context black hole

Translators see a key and a source string:

Key: checkout.summary.total_label
Value: "Total"

They don't see the UI. "Total" in English is unambiguous. In German, it's three different words depending on context:

Table column header → "Gesamt"
Button text → "Gesamtbetrag"
Invoice line item → "Summe"

Your translator picks one. It's wrong. You get a bug report from a German user. A developer screenshots the UI, explains the context in Slack, the translator fixes it, and the fix goes through the deployment pipeline.

This cycle repeats 5-10 times per sprint. Each cycle involves a developer context-switch (15 min), a Slack thread (30 min round-trip), and a deployment (15-45 min). That's 1-2 hours per mistranslation.

What reduces this

AI translation with glossary enforcement. Define domain-specific terms once:

| Term (EN)    | Term (DE)       | Context                    |
|--------------|-----------------|----------------------------|
| Total        | Gesamt          | Summary labels, headers    |
| Workspace    | Arbeitsbereich  | Not "Arbeitsplatz"         |
| Dashboard    | Dashboard       | Keep English (UX standard) |
| Provider     | Anbieter        | Service provider context   |

When AI translates a new key, it checks the glossary first. "Total" always becomes "Gesamt" in summary contexts. Consistency that's mechanically impossible when human translators work independently across 800+ keys.

Screenshot context on keys. Attach a visual reference to each key so translators see the component, not just the string.
Review workflow with diff. Translators see what changed, not the entire file. When a developer changes "Total" to "Subtotal", the translator sees the before/after in context.

Problem 6: The type safety gap

This one is specific to TypeScript projects. Your translation keys are strings. Your IDE doesn't know which keys exist. You type t('header.buttn_text') with a typo, and you find out when a user reports a blank button.

// No error at compile time. No error at build time. Error at runtime.
const title = t('dashbord.title'); // typo: should be 'dashboard.title'

i18next has @types/i18next which can provide type checking if you configure it correctly. FormatJS has similar support. But both require you to generate type definitions from your JSON files and keep them in sync. That's another CI step, another file to maintain, another thing that can go stale.

What actually works

Generate types from the source of truth (the platform), not from local files:

$ npx @better-i18n/cli generate-types

Generated src/i18n.d.ts with 2,072 typed keys

// IDE autocomplete for every key. Red squiggly on typos.
const t = useTranslations('dashboard');
t('title');        // ✅ autocomplete
t('titl');         // ❌ TypeScript error: 'titl' not in DashboardKeys
t('stats.users');  // ✅ autocomplete with nested keys

The type file is generated from the platform's key inventory, which is the same data the CDN serves. One source of truth, zero drift.

The real scaling checklist

Framework comparisons evaluate the 10% of i18n work that involves writing t() calls. Here's what you should actually evaluate when your project passes 500 keys:

Question	File-based answer	CDN-first answer
How do you detect unused keys?	Manual audit or regex script	AST scanner in CI
How do you fix a translation typo?	Full deploy (15-45 min)	CDN publish (30 sec)
How do you avoid merge conflicts?	Namespace splitting (reduces, doesn't eliminate)	No locale files in repo
How do translators get context?	Screenshot in Slack	Attached to key, AI-assisted
How do you ensure key type safety?	Generated types from local JSON (drift risk)	Generated types from platform (single source)
How long is your translation pipeline?	Dev → TMS → PR → Merge → Build → Deploy	Dev → Platform → CDN
What's your cost per language added?	Linear: new files, new conflicts, new translations	Sublinear: glossary-enforced AI + human review

The migration is not the hard part

If you're currently running i18next or FormatJS with file-based translations, the migration to a CDN-first model is straightforward:

Export your current JSON files (you already have them)
Import into a translation platform via CLI
Replace i18next.init({ backend: { loadPath } }) with getMessages({ project, locale })
Remove the locales/ directory from your repo
Run the AST scanner to verify key coverage

Steps 1-4 took our team about 4 hours. Step 5 found 340 unused keys in 30 seconds.

The framework you use for t() calls barely changes. The infrastructure around it changes completely.

What I'd recommend today

Pick any modern i18n library. i18next, FormatJS, or next-intl — they all handle the t() function well. This is the least important decision you'll make.
Don't split into namespace files. Use logical key prefixes (billing.errors.cardDeclined) without file boundaries. Let the CDN serve everything in one cached response.
Set up AST scanning from day one. The longer you wait, the more ghost keys accumulate. Run it in CI so unused keys are caught in the PR that removes them.
Decouple translations from deployments immediately. A translation fix should never trigger a build. This alone will save your team hours per week.
Build a glossary before you translate. 40 domain-specific terms in a glossary produces more consistent translations than a 10-page style guide nobody reads.
Measure developer time on i18n. Track it for one sprint. Count the merge conflicts, the Slack threads with translators, the namespace debates, the deployment time on copy-only changes. The number will be higher than you expect.

Our team uses Better i18n for CDN-delivered translations, AST key scanning, and AI translation with glossary enforcement. If you're evaluating your i18n infrastructure, the free tier is enough to test whether the CDN-first model works for your workflow.

How I Set Up i18n in My React/Next.js App Without Losing My Mind

Eray Gündoğmuş — Sun, 01 Mar 2026 14:04:45 +0000

Last month I shipped a SaaS app in 6 languages. The translation part took me 2 days. Not 2 weeks. Two days.

If you've ever set up internationalization in a production app, you know that sounds suspicious. The typical i18n story goes like this: you spend a day configuring the library, another day wiring up translation files, then you lose the next two weeks chasing down missing keys, syncing JSON files back and forth with translators, and praying that your build doesn't break because someone added a comma in the wrong place.

I want to share what actually worked for me, and the specific decisions that saved me from the usual i18n death spiral.

The problem nobody warns you about

Every i18n tutorial starts the same way: install a library, create a locales/ folder, add some JSON files. Done!

Except that's only 10% of the work.

The other 90% is:

Key management - Who decides the key names? What happens when you rename a component and forget to update the key? What about unused keys from features you deleted 3 months ago?
Translation sync - Your translator works in a spreadsheet or a separate SaaS tool. You work in Git. Someone has to bridge that gap manually, every single sprint.
Deployment coupling - You fix a typo in the French translation. Now you need a full redeploy to push that one-character change to production.
Type safety - You call t("header.buttn_text") with a typo, and you don't find out until a user reports a blank button in production.

These are the problems that make i18n painful at scale. The library choice matters far less than your workflow around it.

My setup (and why I chose it)

I'll walk through the actual stack I used, with code. The app is a Next.js 14 project with TypeScript.

Step 1: Pick a translation format

I went with ICU MessageFormat. Not because it's trendy, but because it handles pluralization without ugly hacks:

// Bad: separate keys for every plural form
"items_zero": "No items"
"items_one": "1 item"
"items_other": "{count} items"

// Good: one ICU key handles all cases
"items": "{count, plural, =0 {No items} one {1 item} other {{count} items}}"

ICU is the format used by react-intl (FormatJS) and @better-i18n/use-intl. It's also what most professional translators already know.

Step 2: Set up the provider

Here's the minimal setup:

// app/[locale]/layout.tsx
import { BetterI18nProvider } from '@better-i18n/use-intl';
import { getMessages } from '@better-i18n/use-intl/server';

export default async function LocaleLayout({
  children,
  params: { locale }
}: {
  children: React.ReactNode;
  params: { locale: string };
}) {
  const messages = await getMessages({
    project: 'my-app',
    locale
  });

  return (
    <BetterI18nProvider locale={locale} messages={messages}>
      {children}
    </BetterI18nProvider>
  );
}

The getMessages call fetches translations from a CDN at build/request time. No local JSON files to maintain.

Step 3: Use translations in components

import { useTranslations } from '@better-i18n/use-intl';

function PricingCard({ plan }) {
  const t = useTranslations('pricing');

  return (
    <div>
      <h3>{t('plan.title', { name: plan.name })}</h3>
      <p>{t('plan.description')}</p>
      <span>{t('plan.price', { amount: plan.price })}</span>
      <button>{t('cta')}</button>
    </div>
  );
}

Nothing revolutionary here. Every i18n library has a t() function. The difference is what happens next.

Step 4: Handle routing

For multilingual SEO, you need locale-prefixed URLs: /en/pricing, /de/pricing, /fr/pricing.

With Next.js App Router:

// middleware.ts
import { createI18nMiddleware } from '@better-i18n/next';

export default createI18nMiddleware({
  locales: ['en', 'de', 'fr', 'es', 'pt', 'ja'],
  defaultLocale: 'en',
});

export const config = {
  matcher: ['/((?!api|_next|.*\\..*).*)'],
};

This middleware detects the user's preferred language from the Accept-Language header, checks if the URL already has a locale prefix, and redirects accordingly.

Important for SEO: use 301 redirects (not 302) for locale redirects. A 302 tells Google "this is temporary" and it won't pass link equity to the localized page.

Step 5: Add hreflang tags

This is where most tutorials stop, and where most sites get penalized. Every localized page needs <link rel="alternate" hreflang="x"> tags pointing to all its language variants:

// app/[locale]/layout.tsx
export function generateMetadata({ params: { locale } }) {
  const locales = ['en', 'de', 'fr', 'es', 'pt', 'ja'];
  const path = /* current path without locale */;

  return {
    alternates: {
      canonical: `https://myapp.com/${locale}/${path}`,
      languages: Object.fromEntries(
        locales.map(l => [l, `https://myapp.com/${l}/${path}`])
      ),
    },
  };
}

Rules that took me way too long to figure out:

Every hreflang URL must return HTTP 200. If /en/about redirects to /about, Google ignores the hreflang and you get "conflicting hreflang" errors in Search Console.
Include a x-default hreflang pointing to your primary language. This tells Google what to show users whose language you don't support.
Hreflang tags must be bidirectional. If /en/about says "my French version is /fr/about", then /fr/about must also say "my English version is /en/about".

Step 6: Structured data per locale

If you have Organization, Product, or Article schema markup, the name and description fields should match the page language:

const structuredData = {
  '@context': 'https://schema.org',
  '@type': 'SoftwareApplication',
  name: t('schema.appName'),
  description: t('schema.appDescription'),
  applicationCategory: 'DeveloperApplication',
  operatingSystem: 'Web',
  offers: {
    '@type': 'Offer',
    price: 0,
    priceCurrency: 'USD',
  },
};

Google specifically looks for language consistency between the page content and structured data. A page in German with English schema markup sends mixed signals.

The workflow that actually scales

Here's where the library comparison stops mattering and the workflow starts mattering.

The old way (what I did before)

1. Developer adds t("newFeature.title") in code
2. Developer manually adds "newFeature.title": "" to en.json
3. Developer commits, pushes, creates PR
4. PM exports en.json, uploads to translation tool
5. Translator translates in the tool
6. PM downloads de.json, fr.json, es.json...
7. PM creates a PR with the new JSON files
8. Merge conflicts. Always merge conflicts.
9. Repeat steps 4-8 for every sprint

This workflow has a person-shaped bottleneck in the middle. The PM becomes a full-time JSON file courier.

The Git-native way

What I do now:

1. Developer adds t("newFeature.title") in code
2. CLI scans the codebase automatically, discovers new keys
3. AI translates with glossary-aware context
4. Translations land as a GitHub PR for review
5. Approved translations deploy to CDN instantly

Steps 2-5 are automated. No JSON files to commit. No merge conflicts. No PM spending their Tuesday copying cells from Google Sheets.

The key insight: translations should flow through the same system as your code (Git), but deploy independently (CDN).

When a translator fixes a typo in the Spanish copy, that fix goes live in seconds through the CDN. No build. No deploy. No release cycle.

Automatic key discovery

This is the feature I didn't know I needed until I had it. The CLI scans your codebase for t() calls and builds a manifest of every translation key:

npx @better-i18n/cli scan

Output:

Discovered 847 translation keys
  - 12 new keys (not yet translated)
  - 3 unused keys (safe to remove)
  - 832 up to date

Those 3 unused keys? They're from a feature I removed last month. Without the scanner, they'd sit in the JSON files forever, confusing every translator who encounters them.

Framework-specific gotchas

Next.js App Router

Server Components can't use useTranslations() (it's a hook). You need the server import:

// Server Component
import { getTranslations } from '@better-i18n/use-intl/server';

export default async function Page({ params: { locale } }) {
  const t = await getTranslations({ locale, namespace: 'home' });
  return <h1>{t('title')}</h1>;
}

// Client Component
'use client';
import { useTranslations } from '@better-i18n/use-intl';

export function CTAButton() {
  const t = useTranslations('home');
  return <button>{t('cta')}</button>;
}

React (Vite / CRA)

No server components, so everything uses the hook:

import { BetterI18nProvider, useTranslations } from '@better-i18n/use-intl';

function App() {
  return (
    <BetterI18nProvider
      project="my-app"
      locale={detectedLocale}
      messages={messages}
    >
      <Router />
    </BetterI18nProvider>
  );
}

Vue 3

<script setup>
import { useI18n } from '@better-i18n/vue';
const { t } = useI18n();
</script>

<template>
  <h1>{{ t('home.title') }}</h1>
  <p>{{ t('home.description') }}</p>
</template>

React Native (Expo)

Mobile has an extra requirement: offline support. Users open your app on a plane and you can't fetch translations from a CDN.

import { BetterI18nExpoProvider } from '@better-i18n/expo';
import fallback from './locales/en.json';

export default function App() {
  return (
    <BetterI18nExpoProvider
      projectId="my-app"
      defaultLocale="en"
      fallbackMessages={fallback}
    >
      <Navigation />
    </BetterI18nExpoProvider>
  );
}

The Expo provider caches translations locally and uses the bundled fallback when offline. When connectivity returns, it pulls fresh translations from the CDN in the background.

The SEO checklist I wish I had on day one

After getting 1,775 hreflang errors in one Semrush crawl (true story), I built myself a checklist. Here it is:

[ ] Every locale URL returns HTTP 200 (not a redirect)
[ ] Canonical tags use the locale-prefixed URL (/en/about, not /about)
[ ] Hreflang tags are bidirectional across all locales
[ ] x-default hreflang points to your primary language
[ ] Sitemap includes all locale variants
[ ] Structured data fields are translated (not English-only)
[ ] <html lang="xx"> matches the page locale
[ ] <title> tags are under 70 characters (watch out for German, it's 30% longer than English)
[ ] Redirects use 301, not 302/307
[ ] OG tags are localized (og:title, og:description, og:locale)

AI-powered translation with guard rails

I'll be honest: I use AI translation for the first pass. It saves days of work. But raw machine translation shipped straight to production is a bad idea.

What works is a review workflow:

AI translates with access to your glossary (so it knows "workspace" is always "Arbeitsbereich" in German, not "Arbeitsplatz")
Native speaker reviews the AI output, approves or edits
Approved translations deploy to CDN

The glossary part is critical. Without it, AI translates the same term differently across pages. Your "Dashboard" becomes "Armaturenbrett" on one page and "Instrumententafel" on another.

What I'd do differently

If I started over:

Set up i18n on day one, not day 100. Retrofitting t() calls into 200 components is brutal. Starting with i18n means every new component uses translation keys from the start.
Use ICU format from the beginning. I started with simple key-value JSON and had to migrate when I needed pluralization. ICU handles plurals, dates, numbers, and gender from day one.
Automate the key discovery early. The CLI scanner caught 47 unused keys in my codebase. That's 47 strings translators were spending time on for no reason.
Don't skip the SEO fundamentals. Hreflang, canonical tags, and locale routing are not optional if you want organic traffic from non-English markets. I learned this by losing 3 months of German organic traffic to indexing issues.

Wrapping up

The library you pick for t() calls matters less than you think. What matters is:

Can your translators work without needing a developer to shuffle files around?
Can you fix a translation without triggering a full deploy?
Do you know which keys are unused and which are missing?
Are your localized pages actually indexed correctly?

If the answer to any of those is "no", you have a workflow problem, not a library problem.

I'm using Better i18n for my projects. It handles the Git sync, CDN delivery, AI translation, and key discovery parts so I can focus on building features instead of managing JSON files. The free tier covers small projects; the Pro plan at $19/month works for production apps with multiple locales.

Whatever tool you pick, get the workflow right first. The code is the easy part.

Stop Managing Translations in JSON Files — There's a Better Way

Eray Gündoğmuş — Sun, 01 Mar 2026 13:21:41 +0000

Every multilingual app starts the same way:

locales/
├── en.json    ← 12 keys
├── tr.json    ← 12 keys
└── de.json    ← 12 keys

Six months later:

locales/
├── en.json    ← 847 keys
├── tr.json    ← 791 keys (56 missing, nobody knows which)
├── de.json    ← 823 keys (24 orphaned from a deleted feature)
├── ja.json    ← 402 keys (translator quit halfway)
└── ar.json    ← 0 keys (we said we'd get to it)

If this looks familiar, keep reading.

The Real Problem

The issue isn't JSON files. JSON is fine. The problem is that translations live outside your development workflow.

Your code goes through pull requests, CI checks, type checking, and automated tests. Your translations? Someone exports a spreadsheet, a translator fills in cells, and someone else copies the values into JSON files. No review. No validation. No automated checks.

This means:

Keys drift — a developer renames save_draft to save_as_draft in code, but the translation files still have save_draft
Dead keys accumulate — features get deleted, translation keys don't
Format errors hide — {count, plural, one {# item} other {# items}} is easy to break and hard to spot
Deploys block on translations — fixing a typo requires a full rebuild

What if translations worked like code?

That's what we built with Better i18n. Here's the workflow:

Developer adds t('pricing.title') in code
        ↓
CLI scans the codebase, detects the new key
        ↓
Key appears in the translation dashboard
        ↓
Translator (or AI) adds the translation
        ↓
Better i18n creates a PR in your GitHub repo
        ↓
Team reviews the PR → CI checks pass → merge
        ↓
CDN cache updates → users see the new translation

No JSON file juggling. No manual exports. No "did we translate this?" Slack messages.

Let's Build It

I'll walk through setting up a Next.js app with Better i18n. The same principles apply to React and React Native — I'll cover those at the end.

Step 1: Install

npm install @better-i18n/next @better-i18n/cli

Two packages:

@better-i18n/next — middleware, hooks, server component support
@better-i18n/cli — scans your code, syncs with the platform

Step 2: Middleware for Locale Routing

// middleware.ts
import { createI18nMiddleware } from '@better-i18n/next';

export default createI18nMiddleware({
  locales: ['en', 'tr', 'de', 'ja'],
  defaultLocale: 'en',
});

export const config = {
  matcher: ['/((?!api|_next|.*\\..*).*)'],
};

This gives you:

/about → English (default)
/tr/about → Turkish
/de/about → German
Automatic detection from Accept-Language header
Locale persistence via cookies

Step 3: Use Translations in Your Components

import { useTranslations } from '@better-i18n/next';

export default function PricingPage() {
  const t = useTranslations('pricing');

  return (
    <main>
      <h1>{t('title')}</h1>
      <p>{t('subtitle')}</p>

      {plans.map(plan => (
        <div key={plan.id}>
          <h3>{t(`plans.${plan.id}.name`)}</h3>
          <p>
            {t('price_per_month', {
              amount: plan.price,
              currency: plan.currency
            })}
          </p>
          <ul>
            {plan.features.map(f => (
              <li key={f}>{t(`features.${f}`)}</li>
            ))}
          </ul>
        </div>
      ))}
    </main>
  );
}

The translation file for this might look like:

{
  "pricing": {
    "title": "Simple, transparent pricing",
    "subtitle": "No hidden fees. Cancel anytime.",
    "price_per_month": "{amount, number, currency} / month",
    "plans": {
      "starter": { "name": "Starter" },
      "pro": { "name": "Pro" },
      "enterprise": { "name": "Enterprise" }
    },
    "features": {
      "unlimited_projects": "Unlimited projects",
      "github_sync": "GitHub sync",
      "ai_translation": "AI-powered translation",
      "cdn_delivery": "CDN delivery"
    }
  }
}

Better i18n supports ICU MessageFormat — the same standard used by FormatJS, next-intl, and use-intl. Plurals, dates, numbers, select statements — all handled.

Step 4: Scan Your Codebase

Here's where it gets interesting. Instead of manually tracking which keys exist:

npx @better-i18n/cli scan

Output:

Scanning src/ for translation keys...

✓ Found 847 translation keys across 124 files

  New keys (not yet translated):
    + pricing.plans.enterprise.name
    + pricing.features.cdn_delivery

  Unused keys (not found in code):
    - settings.old_theme_toggle
    - onboarding.deprecated_step_3

  Missing translations:
    ⚠ tr: 12 keys missing
    ⚠ de: 3 keys missing
    ⚠ ja: 45 keys missing

The CLI uses AST parsing, not regex — so it understands your code structure. It catches dynamic keys, template literals, and namespace patterns.

Step 5: Sync

npx @better-i18n/cli sync

This pushes the scan results to the Better i18n dashboard where translators can work on missing translations. When they're done, a PR lands in your repo.

AI Translation That Understands Context

Most machine translation tools translate strings in isolation. Better i18n sends context to Google Gemini:

Namespace — "this string is in the pricing section"
Glossary — "we translate 'workspace' as 'çalışma alanı' in Turkish"
Nearby keys — "the strings around this one say..."
ICU structure — "this is a plural form, handle it correctly"

The difference is noticeable. Instead of:

// Generic MT
"Workspace" → "Çalışma Alanı" (correct but formal)
"{count} items selected" → "{count} öğe seçildi" (wrong plural form)

You get:

// Context-aware
"Workspace" → "Çalışma alanı" (matches glossary casing)
"{count, plural, one {# öğe seçildi} other {# öğe seçildi}}" (correct ICU)

Bonus: Let AI Agents Handle It

We built an MCP server so AI assistants can manage translations directly:

npm install @better-i18n/mcp

Connect it to Claude, Cursor, or Windsurf, and you can:

You: "Add the key 'dashboard.welcome_back' with value
      'Welcome back, {name}!' and translate it to Turkish and German"

AI:  Creates the key, translates it, and the changes flow
     through your GitHub PR workflow.

The Model Context Protocol is becoming the standard for connecting AI assistants to external tools. If you're not using it yet, it's worth exploring.

React Native / Expo

Mobile apps need offline support and OTA translation updates. The @better-i18n/expo package handles both:

import { BetterI18nExpoProvider, useTranslations } from '@better-i18n/expo';

export default function App() {
  return (
    <BetterI18nExpoProvider
      projectId="your-project-id"
      defaultLocale="en"
      fallbackMessages={require('./messages/en.json')}
    >
      <RootNavigator />
    </BetterI18nExpoProvider>
  );
}

What you get:

Offline-first — translations cached locally, works without network
Background updates — new translations fetched silently, no app store update
Bundled fallback — ships with default translations so the app works on first launch
Automatic locale detection — reads device language settings

The Full Picture

Here's what the complete workflow looks like:

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│  Developer   │────▶│  GitHub Repo  │◀────│  Translator  │
│  (adds key)  │     │  (source of   │     │  (via Better  │
│              │     │   truth)      │     │   i18n UI)   │
└─────────────┘     └──────┬───────┘     └─────────────┘
                           │
                    ┌──────▼───────┐
                    │   CDN Edge    │
                    │  (Cloudflare) │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
         ┌────────┐  ┌────────┐  ┌────────┐
         │ Next.js │  │ React  │  │  Expo  │
         │  App    │  │  App   │  │  App   │
         └────────┘  └────────┘  └────────┘

No separate translation pipeline. No manual exports. No "which JSON file has the latest version?" conversations.

Try It

The SDKs are open source under MIT:

better-i18n / oss

Official TypeScript SDKs for Better i18n — Next.js, React, Expo/React Native integrations with CLI, MCP server, and CDN-powered translation delivery

TypeScript SDKs for the Better i18n localization platform

Manage translations with CDN delivery, GitHub sync, and AI-powered workflows
Documentation · Website · Blog

Why Better i18n?

Most localization tools weren't built for modern developer workflows. Better i18n is different:

GitHub-native — translations sync as PRs, reviews happen in your existing workflow
CDN-delivered — translations served from Cloudflare's edge network, updated without redeployment
AI-powered — context-aware translation with Google Gemini, not word-by-word machine output
TypeScript-first — full type safety across Next.js, React, Expo, and React Native
MCP-ready — AI agents can manage translations through the Model Context Protocol

How it compares

Feature	Better i18n	Crowdin	Lokalise	Phrase
GitHub-first workflow	✅	Partial	Partial	❌
AI translation with context	✅	✅	✅	✅
CDN delivery (no redeploy)	✅	❌	❌	❌
TypeScript SDKs	✅	❌	❌	❌
MCP server for AI agents	✅	❌	❌	❌
CLI scanner

…

View on GitHub

Links:

better-i18n.com — platform (free tier available)
docs.better-i18n.com — documentation
npm packages — all published SDKs
AI agent skills — i18n best practices for AI assistants

If you have questions, drop a comment below or open an issue on GitHub.

GPT-4 and GitHub Actions for PR Review Automation: AI Code Reviewer

Eray Gündoğmuş — Sun, 12 Nov 2023 14:16:24 +0000

Pull request reviews generally involve exchanging ideas with team members to improve code quality, passing our written code through a pipeline with certain automation tools, and allow us to use our time more efficiently and systematically.

Following advancements in artificial intelligence, I thought, why not benefit from AI in an area as crucial for software development teams as "Pull request review?" After some research, I came across a solution: AI Code Reviewer.

AI Code Reviewer is an innovative tool that can perform automatic code reviews for pull requests in an integrated manner with GitHub Actions using OpenAI's GPT-4 technology. This tool is designed to facilitate the software development process and offers developers valuable feedback by intelligently identifying potential issues and improvement opportunities in their code. AI Code Reviewer examines pull requests in real time, provides detailed suggestions for code changes, and makes customizable comments. It also focuses only on important areas by excluding certain files and patterns. This tool is an ideal solution for teams looking to enhance code quality and manage development processes efficiently.

I am aware that there are tools like SonarQube that analyze code quality, control rules, and patterns. However, AI Code Reviewer offers a different approach by providing more dynamic and context-sensitive automatic reviews in pull requests using OpenAI's GPT-4 technology.

While SonarQube detects overall code quality and security vulnerabilities through static code analysis, AI Code Reviewer provides customizable and interactive feedback by examining code changes in real time and integrates with GitHub. Therefore, it can be said that both tools serve different needs in the software development process and complement each other.

Setup

To use AI Code Reviewer in GitHub Actions, obtain an OpenAI API key.
Save the OpenAI API key as a GitHub Secret value named OPENAI_API_KEY.

Create a folder named ".github" and add another folder named "workflows." Then create a file named "[name].yml" inside it and paste the following content into the file.

name: AI Code Reviewer

on:
  pull_request:
    types:
      - opened
      - synchronize
permissions: write-all
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3

      - name: AI Code Reviewer
        uses: your-username/ai-codereviewer@main
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          OPENAI_API_MODEL: "gpt-4" # Optional: defaults to "gpt-4"
          exclude: "**/*.json, **/*.md" # Optional: exclude patterns separated by commas

Actually that's all! Now:

Customize the "exclude" feature to specify files you don't want to be reviewed.
Commit your changes. Now, AI Code Reviewer will be working on your next pull request.

Thanks to this tool, we will now receive AI support before our team members and make the job easier for those who will review.

Wishing everyone good work.

About me
As a frontend engineer with a passion for open-source work, I take pride in my ability to deliver high-quality results to clients. My experience and expertise have equipped me with the skills needed to develop innovative solutions that exceed expectations. As an active member of the tech community, I value the importance of open communication, continuous learning, and collaboration. If you're interested in learning more about my work or how I can contribute to your project, feel free to connect with me.

Simplifying Client-Side Authentication with Firebase and SvelteKit

Eray Gündoğmuş — Sun, 12 Nov 2023 14:10:03 +0000

Authentication tasks can often be a complex and challenging aspect of web development. If you've never worked with Firebase before, you're in luck. In this article, I've created a sample repository that's not just for learning purposes but can also be used in a production environment. We'll explore how to use Firebase Authentication seamlessly with SvelteKit and TypeScript, making the authentication process smoother and more efficient.

Firebase Authentication provides backend services, easy-to-use SDKs, and ready-made UI libraries to authenticate users to your app. It supports authentication using passwords, phone numbers, popular federated identity providers like Google, Facebook and Twitter, and more.

Understanding Firebase Authentication

Before diving into the implementation details, let's briefly discuss what Firebase Authentication offers. Firebase Authentication is a robust backend service that provides developers with user authentication capabilities. It offers an easy-to-use SDK and pre-built UI libraries that allow you to authenticate users to your web application effortlessly. Firebase supports a wide range of authentication methods, including email/password, phone numbers, and federated identity providers like Google, Facebook, and Twitter.

Creating a SvelteKit project

To begin, we'll set up a new SvelteKit project. If you're new to SvelteKit, you can quickly create a project using the following commands:

npm create svelte@latest my-app
cd myapp

Install Firebase Emulator

Next, we'll integrate Firebase into our SvelteKit project. Firebase provides a suite of services, and for this article, we're focusing on Firebase Authentication. But before we proceed, we'll set up Firebase Emulators for local development. Firebase Emulators allow us to test authentication locally, ensuring smooth development.
To set up Firebase Emulators, you need to install the Firebase CLI and initialize your Firebase project:Local development with Local Emulator Suite can be a good fit for your evaluation, prototyping, development and continuous integration workflows.

Installing Firebase CLI

npm install -g firebase-tools

Or you can download CLI manually.

After installing Firebase CLI, you need to login to your Google account.

firebase login

Then, you need to initialize Firebase project in your project directory.

firebase init

During the initialization process, choose Firebase Emulators, and select the Firebase project you want to use. Also, make sure to select the Authentication emulator.
After installation we will be ready to use Firebase Auth Emulator.

Install Firebase

In your project folder run the following command.

npm install firebase

After the installation, create a firebase.client.ts file in src/lib folder.

import { initializeApp } from 'firebase/app';
import { connectAuthEmulator, getAuth } from 'firebase/auth';
import type { FirebaseApp } from 'firebase/app';
import type { Firestore } from 'firebase/firestore';
import type { Auth } from 'firebase/auth';
import { browser } from '$app/environment';

export let db: Firestore;
export let app: FirebaseApp;
export let auth: Auth;

const firebaseConfig = {
 apiKey: import.meta.env.VITE_FIREBASE_API_KEY,
 appId: import.meta.env.VITE_FIREBASE_APP_ID,
 useEmulator: import.meta.env.VITE_FIREBASE_USE_EMULATOR === 'true',
 authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN
};

export const initializeFirebase = () => {
 if (!browser) {
  throw new Error("Can't use the Firebase client on the server.");
 }
 if (!app) {
  app = initializeApp(firebaseConfig);
  auth = getAuth(app);

  if (firebaseConfig.useEmulator) {
   connectAuthEmulator(auth, 'http://127.0.0.1:9099');
  }
 }
};

This is our base code to initialize Firebase for our project. All the config variables we are going to need will be in .env file.

VITE_FIREBASE_API_KEY=API_KEY_HERE
VITE_FIREBASE_APP_ID=APP_ID_HERE
VITE_FIREBASE_USE_EMULATOR=true # true in development, false in production
VITE_FIREBASE_AUTH_DOMAIN=AUTH_DOMAIN_HERE

Now to invoke this initializeFirebase function in our project, let's create a +layout.ts file in src/routes and add our load function that we are going to use on +layout.svelte page.

/** @type {import('./$types').LayoutLoad} */

import { initializeFirebase, auth } from '$lib/firebase.client';
import { browser } from '$app/environment';
import { onAuthStateChanged } from 'firebase/auth';

export async function load({ url }) {
 if (browser) {
  try {
   initializeFirebase();
  } catch (ex) {
   console.error(ex);
  }
 }

 function getAuthUser() {
  return new Promise((resolve) => {
   onAuthStateChanged(auth, (user) => resolve(user ? user : false));
  });
 }

 return {
  getAuthUser: getAuthUser,
  url: url.pathname
 };
}

Now our load function will get auth user on auth state changed. If user is not logged in, it will return false on mount.

Creating the State

To manage the authentication state in your SvelteKit app, we'll create a session.ts file in the src/lib folder. This file will define the session state and export a session store.

import { writable, type Writable } from 'svelte/store';

type User = {
 email?: string | null;
 displayName?: string | null;
 photoURL?: string | null;
 uid?: string | null;
};

export type SessionState = {
 user: User | null;
 loading?: boolean;
 loggedIn?: boolean;
};

export const session = <Writable<SessionState>>writable();

Using Layout page

Now to use our load function, let's create +layout.svelte page

<script lang="ts">
 import { onMount } from 'svelte';
 import { session } from '$lib/session';
 import { goto } from '$app/navigation';
 import { signOut } from 'firebase/auth';
 import { auth } from '$lib/firebase.client';

 import type { LayoutData } from './$types';
 export let data: LayoutData;

 let loading: boolean = true;
 let loggedIn: boolean = false;

 session.subscribe((cur: any) => {
  loading = cur?.loading;
  loggedIn = cur?.loggedIn;
 });

 onMount(async () => {
  const user: any = await data.getAuthUser();

  const loggedIn = !!user && user?.emailVerified;
  session.update((cur: any) => {
   loading = false;
   return {
    ...cur,
    user,
    loggedIn,
    loading: false
   };
  });

  if (loggedIn) {
   goto('/');
  }
 });

</script>
<!-- +layout.svelte -->

{#if loading}
 <div>Loading...</div>
{:else}
  <div>
   Logged in: {loggedIn}
   <slot />
  </div>
{/if}

Building a Login Page

We'll start by creating a basic login form. In your Svelte page, you can create the login form and handle authentication actions.

<!-- login/+page.svelte -->

<div class="login-form">
 <h1>Login</h1>
 <form on:submit={loginWithMail}>
  <input bind:value={email} type="text" placeholder="Email" />
  <input bind:value={password} type="password" placeholder="Password" />
  <button type="submit">Login</button>
 </form>

 <div>or</div>

 <button on:click={loginWithGoogle}>Login with Google</button>
 <div>Don't you have an account? <a href="/register"> Register</a></div>
</div>

In the script part of our Svelte page, we are going to add our functionality.

<script lang="ts">
// login/+page.svelte
 import { session } from '$lib/session';
 import { auth } from '$lib/firebase.client';
 import {
  GoogleAuthProvider,
  signInWithPopup,
  signInWithEmailAndPassword,
  type UserCredential
 } from 'firebase/auth';
 import { goto } from '$app/navigation';

 let email: string = '';
 let password: string = '';

 async function loginWithMail() {
  await signInWithEmailAndPassword(auth, email, password)
   .then((result) => {
    const { user }: UserCredential = result;
    session.set({
     loggedIn: true,
     user: {
      displayName: user?.displayName,
      email: user?.email,
      photoURL: user?.photoURL,
      uid: user?.uid
     }
    });
    goto('/');
   })
   .catch((error) => {
    return error;
   });
 }

 async function loginWithGoogle() {
  const provider = new GoogleAuthProvider();
  await signInWithPopup(auth, provider)
   .then((result) => {
    const { displayName, email, photoURL, uid } = result?.user;
    session.set({
     loggedIn: true,
     user: {
      displayName,
      email,
      photoURL,
      uid
     }
    });

    goto('/');
   })
   .catch((error) => {
    return error;
   });
 }
</script>

Building a Register Page

<script lang="ts">
 // register/+page.svelte
 import { auth } from '$lib/firebase.client';
 import { createUserWithEmailAndPassword } from 'firebase/auth';
 import { goto } from '$app/navigation';
 import { session } from '$lib/session';

 let email: string = '';
 let password: string = '';

 async function handleRegister() {
  await createUserWithEmailAndPassword(auth, email, password)
   .then((result) => {
    const { user } = result;
    session.update((cur: any) => {
     return {
      ...cur,
      user,
      loggedIn: true,
      loading: false
     };
    });
    goto('/');
   })
   .catch((error) => {
    throw new Error(error);
   });
 }
</script>

<!-- register/+page.svelte -->
<div class="register-form">
 <form on:submit={handleRegister}>
  <h2>Register</h2>
  <input bind:value={email} type="text" placeholder="Email" />
  <input bind:value={password} type="password" placeholder="Password" />
  <button type="submit">Register</button>
 </form>
</div>

In this article, we've walked through the process of integrating Firebase Authentication with a SvelteKit application. We've covered setting up Firebase Emulators for local development, initializing Firebase in your project, managing authentication state, and implementing login and registration features. This combination of Firebase and SvelteKit offers a powerful and streamlined solution for client-side authentication.

As you continue to work on your project, you can build upon these foundations and explore additional Firebase features to enhance the user experience and security of your web application.

By following these steps, you can simplify client-side authentication and create a secure and user-friendly web application using Firebase and SvelteKit.

GitHub Repository: SvelteKit Firebase Authentication Example

In this example project, you'll see how all the pieces come together. You can examine the project structure, review the implementation of authentication features, and use it as a reference for your own projects.
Here are some key points about the example project:
It showcases the integration of Firebase Authentication with SvelteKit, just as we discussed in this article.
You can explore how Firebase Emulators are set up for local development.
The project includes login and registration pages with email/password and Google authentication methods.
The management of authentication state using Svelte's stores is also demonstrated.
Feel free to clone, fork, or download the project for your own use. It's a practical resource to accelerate your development when working on projects that require user authentication.

By examining the example project alongside this article, you'll gain a more comprehensive understanding of how to implement Firebase Authentication with SvelteKit effectively.

Happy coding!

What other teams did on Disaster Map in first 72 hours

Eray Gündoğmuş — Tue, 21 Feb 2023 20:50:21 +0000

An application was developed on the first day in the field of artificial intelligence that converts text from a screenshot and extracts address, phone, and name information from this text and saves it to a database. EasyOCR was used to convert text and the OpenAI DaVinci model was trained to extract the address. On the third day, a model training was started using this model on a tweet that meets their needs. This model would be able to distinguish their needs.
The legal team tried to support "Açık Yazılım Ağı" by preparing necessary legal texts for the personal data to be processed during this process, informing team members voluntarily about the risks that may be encountered, and providing legal advice. This was necessary due to the nature of the work done in terms of personal data.
Test teams channeled our human resources to certain projects and tasks according to needs and requirements and made people who volunteered to lead responsible for planning. Afterwards, they started testing and created high-level requirements by documenting them. They detailed the errors in an Excel document, prioritized them, and moved them to GitHub, i.e. development teams.
Moderation teams quickly directed incoming people on the server to relevant teams and channels to contribute, improved role settings to enable each team to work faster and more stable. Additionally, they constantly monitored and cleared spam and harmful messages on the server. Afterwards, they kept active communication with teams and solved communication issues such as informing and announcements.
As the Cloud & Infra & DevOps team, they preferred cloud solutions together with the urgency of the process. They dockerized the projects and created CI&CD pipelines for production deployment to cloud environments that would be multi-cloud providers and technology-independent to provide the best support to 1000-person development teams both horizontally and vertically scalable. Thus, codes prepared independently by teams in terms of technology and human resources were deployed live on the relevant branches. They also resolved maintenance and zero downtime efforts by choosing serverless solutions for dependent databases, monitoring, cache, and streaming solutions in cloud environments. All working systems were designed as serverless and HA (high available).
With the realization of application ideas, social media teams started marketing and communication activities to reach more people. Different sub-working groups were formed and organized quickly, from the design of the Açık Yazılım Ağı corporate identity to the preparation of content for social media accounts, collaboration with NGOs, and communication with influencers. Communication regarding applications and the community was done by these teams.

How an Open-Source Disaster Map Helped Thousands of Earthquake Survivors: afetharita.com

Eray Gündoğmuş — Mon, 20 Feb 2023 17:23:38 +0000

Summary

On February 6, 2023, earthquakes measuring 7.8 and 7.6 hit the Kahramanmaraş region of Turkey, affecting 10 cities and resulting in more than 42.000 deaths and 120.000 injuries as of February 21.

In the hours following the earthquake, a group of programmers quickly become together on the Discord server called "Açık Yazılım Ağı" , inviting IT professionals to volunteer and develop a project that could serve as a resource for rescue teams, earthquake survivors, and those who wanted to help: afetharita.com. It literally means "disaster map".

As there was a lack of preparation for the first few days of such a huge earthquake, disaster victims in distress started making urgent aid requests on social media. With the help of thousands of volunteers, we utilized technologies such as artificial intelligence and machine learning to transform these aid requests into readable data and visualized them on afetharita.com. Later, we gathered critical data related to the disaster from necessary institutions and added them to the map.

Disaster Map, which received a total of 35 million requests and 627,000 unique visitors, played a significant role in providing software support during the most urgent and critical periods of the disaster, and helped NGOs, volunteers, and disaster victims to access important information. I wanted to share the process, our experiences, and technical details of this project clearly in writing.

"thanks to "afetharita.com" my friend was saved. all the people on that collapsed building saved."

I should warn you that the article will be quite long. When you read the entire article, you will be able to see the technical perspective of how such a project was developed end-to-end in a short time, how multiple disciplines worked together, how technical decisions were made based on which criteria, how it was managed, and similar topics.

At the beginning

When I joined the frontend team of the project a few hours after the earthquake, I was faced with complete chaos. People wanted to help, but they didn't know how they could contribute. Therefore, we needed to take urgent action and create a plan. As I asked, everyone was thinking about what they could do. At that moment, my friend Zafer suggested that I could take on the map integration. That's how we started contributing to the project.

At this point, I wasn't even aware that I was starting a project that would become an example worldwide.

First 3 hours: Uncertainty

How much time do we have?

Less than limited. We can say very little.

Where is the design?

There is no clear design file yet. However, there may not be enough time to do a detailed design work to advance the project development process quickly.

Who will use the application mostly and on which devices?

Earthquake victims, field teams, and NGOs can use this data. Therefore, it is important to have a clear and user-friendly interface with technical details kept to a minimum. Also, since the closest device to both earthquake victims and moving teams is expected to be the phone, mobile-first interfaces should be developed.

Internet speed?

After an earthquake, internet speed can generally be low in disaster situations. 2G internet speed can be around 0.1 mbs/second on average, while 3G speed can be around 3 mbs/second. Therefore, project developers should coordinate with the backend team to determine the lightest data flow and model, so that users can receive services even in the worst scenarios.

Where were we? Zafer, what's up? Oh yes, the map.

To sum up, the main purpose of this map was to be fast and simple. Considering that internet access is limited in the earthquake zone and users may face significant issues, we aimed to develop an application that works quickly, has a simple user experience and is always functional. This way, NGO volunteers who will reach earthquake victims could quickly see reported locations and provide help.
Since the map was the key element, we had to choose the right technology to use. After discussing it with the team, we decided to use Leaflet.
The reasons for this decision were:

It's open source
It has no external dependencies
It has browser support
It's lightweight with a 42KB bundle size
It's customizable
It's well-documented
It's mobile-friendly

I added the map as a dependency and showed it on the screen in my initial commits.

I thought we would need a modal or page to show details for each point on the map, so I also included the MUI React Drawer component in the project.

The final version of the Drawer component can be seen below.

Additionally, the benefits of choosing Material UI can be summarized as providing a ready-made design system to meet our needs and eliminating the need for component-level testing. On the other hand, its weight is quite heavy (493kb), which can be considered a downside.

What about documentation?

To support and encourage other developer colleagues to contribute, I added README.md and CONTRIBUTING.md to the project after reviewing a few drafts. These documents include details about what to consider before contributing, project installation, code format, and semantic commit for commit messages.

First 12 hours: Proper positioning

Working with Mock API

Eliminating the situation that blocks the frontend development team while waiting for the backend developers is an important step to continue development. As an anonymous backend developer said:

"A good frontend developer is also someone who develops while waiting for the backend."

The frontend team did not need to wait for the API because we knew how the package we would use wanted the data. Therefore, creating a mock API and replacing it with the real API when it was ready would solve our problem.

Rapid delivery

Needs could change, data types could change, interfaces could change, but the fact that we were racing against time would not change.
I realized that it was meaningless to engage in long technical discussions in a development environment where we were racing against time, and I took the initiative to manage this process.

I opened main, rc (release candidate), and development branches to move forward with 3 main branches and added branch protection with the help of my colleagues to create a safe and fast development environment. From now on:

When a PR is opened and approved by the team, it will be merged into the development branch after being tested through Vercel's preview link and receiving approval from at least 2 people.
Changes in the development branch will be merged to the rc branch, so that features that are candidates to go live can be tested in a specific domain (rc.afetharita.com) off of the rc branch.
To release to production, the rc branch will be merged directly into the main branch that is linked to the main domain.
For hotfixes, a copy will be taken from the previous version in the main branch and merged directly.

The second approach I added to the frontend was to implement the Testing in Production (TIP) practice.
Although we had not yet been in touch with the test teams, product managers, and designers, we had to test our software ourselves. In this case, since the likelihood of making mistakes was high, instead of finding a solution to this problem, I decided to prioritize needs and errors coming from the field, which were our product users. As a team, our priority should not be to create a flawless software development process, but to move forward by first doing the simple thing and creating a live product.
Therefore, it was enough for us as a team to perform acceptance tests in the development and rc branches.

Initial Load

Not requesting data for unused elements during the initial load could reduce the data load at the first launch. For our mock API, it was a good solution to only put pins on the locations of notifications during the initial load and make a separate request for details if needed since other detailed data is not used until the page is loaded.

// get pin[]
pin { 
  id: number,
  geo: {
    x: number,
    y: number
  },
}
// get pin details
pinDetails: {
  id: number,
  geo: {...},
  context: {...},
  ...
}

Ease of use, mobile approach, browser and device support

One of the things we needed to pay attention to as a team was user feedback. To address this, we prepared the rc.afetharita.com environment from the moment we received our first deploy, and asked non-technical friends to test it from their phones and report any issues they encountered to us.
Until our test teams joined the project, we tried to gather user feedback as the most important metric.
I added each feedback to a small note and applied it in my work, and shared these feedback with my team members, providing collaboration and exchange of ideas.

Adding map features: Heatmap, clustering, and legend

We started by adding a legend to the map to help users understand which colors represent which data.

We wanted to use the Leaflet.markercluster plugin for clustering. This plugin would cause performance improvement in large data clusters and make map operations faster and smoother. Additionally, its high number of stars (3.6K) and compatibility with the Leaflet.js library were among the reasons why we preferred it.

For the heat map, we chose the react-leaflet-heatmap-layer, a map component for react-leaflet.

First 36 Hours: Recovery

Topics: Chaos, lack of human resource processes, inability to transfer to developers who want to help, Discord usage becoming difficult due to message overload, backend integration, going live.

Chaos

As more people joined the Discord server, we began to face problems such as crowded voice channels and difficulty in pair programming.
In this case, I encouraged users in the voice channels to split into groups and deal with different issues.
However, later on, I noticed a problem where users who wanted to help but couldn't offer meaningful contributions also joined the channels.
While everyone's contributions were valuable, the chaotic environment made development almost impossible. Isolation was necessary, but a measure had to be taken to not miss out on truly valuable ideas amidst the crowd.
For this reason, I requested the necessary changes from the moderators to only allow users with the "afetharita" role to access voice and text channels. This way, we could direct those who had development proposals or error reports directly to GitHub Issues.
With the next topic, this problem would be largely prevented by a wombo-combo.

Pull Request and Issue Templates

Freedom of expression is important as long as it adheres to rules. It was crucial that PR and issue templates had enough detailed explanations to ensure that we understood them correctly. I added encouraging templates for detailed explanations, as shown in the example below.

Sometimes, when adding templates, I felt too strict and authoritarian, but ultimately, I believed that these solutions would work and prevent chaos.

However, there was a problem: who would check the compliance of opened issues and PRs with these templates?

afetharita-checkforce

I brought together reliable, selfless, and dedicated friends whom I knew from the Frontendship channel, where I took the lead as the founder to unite developers in the frontend area and to be an open-source organization, and created a team by giving them triage permissions on GitHub.

This excellent team would review the issues and PRs opened in the repository and tag inappropriate ones as invalid, telling the author to try again in compliance with the rules. In this way, they would take a significant burden off the developers.

ID Checks

GitHub issue IDs were important for fragmented progress and work to form a comprehensible whole. Again, if the opened PR did not refer to an issue ID, the checkforce team asked for the PR to be closed and reopened.

Labels

It was necessary to properly organize and write descriptions of labels, with the participation of the afetharita-checkforce team in the development process. Labels also played a crucial role in making the work process acceptable.

Discord Category & Channel Structure

Considering that not everyone on the server was working on the same project and the potential for Disaster Map to be a flagship, I asked the moderators to do something outside of the server structure.

We separated the Disaster Map categories by discipline to increase isolation.

It would look like the one below in the next 24 hours.

Code Standards

Our top priority was not code quality, but as our codebase grew, our concerns increased, and we faced the risk of creating a chaotic environment. Therefore, we decided to use some tools to maintain code standards.

We included ESlint and Prettier tools in the project and completed their configurations. Additionally, we added a pre-commit hook by creating an intermediate stage with a tool I love, called Husky. Thus, everyone working on the project had to format the code and check for errors before submitting a commit.

We also added the commitlint feature to maintain certain standards for our commit messages by applying semantic commit rules. We noticed that the --no-verify option was used in some pull requests, so we provided a second check with GitHub Actions to prevent this.

API Connection

We learned the data model prepared on the backend side of the project before it was launched, so all we had to do was add an API_URL. We had no problem other than getting a CORS error in the test environment. However, thanks to everyone responding quickly, we almost synchronized the error.

I think the hardest part was still fighting with emotions. The destruction, insomnia, and tension we see on social media. And not just for me. Everyone I talked to had a tired voice and still said they hadn't slept or were about to pass out. As I saw this effort, my faith and hope in humanity increased.

Going live

After completing the necessary developments to print the data on the screen, we took it to the rc environment, tested it after the final checks. However, we were aware that we needed more development for the application. Still, we did not encounter any significant problems during the testing phase. As a result, we deployed on production, thinking that we were ready to make Disaster Map available for use.

My tweet about my 33 hours of effort in 37 hours.

In what I've told so far, I have mainly focused on the frontend part because I was not fully aware of the details of the remaining work.
However, I was sure that one of the biggest team efforts that an open-source community could achieve in Turkey was being carried out. On the Discord server, professionals from every discipline came together and worked towards common goals, with more than 10,000 people at that time. Many people worked intensively day and night, regardless of working hours and time differences.

Click too see what other teams did

First 72 hours: Recovery

While we were not sure whether Disaster Map was being used, we learned from Furkan's announcement that the platform had received 4.2 million views and had helped valuable AKUT teams rescue 160 people from the wreckage.

Although we had established API connection to the backend, we observed that instead of data coming from two separate requests as we had mock-prepared, a data that could cause performance loss was received by providing the list of pins and their details in a single request, and response time could go up to 10 seconds.

Thanks to the presence of experienced and talented colleagues on the frontend side, the system had settled and started working on its own. During this process, we developed a sense of trust in each other and strengthened our cooperation.

However, I was not aware of who I needed to communicate with to synchronize with the backend. After struggling to find answers to my questions for a while, I learned that there were some problems on the backend and that the API side was re-written under the leadership of Emre, who is working as a Senior Software Engineer.

Focusing on the solution, I directly asked how I could help instead of asking questions about the topics I did not know. After learning that Emre had experienced similar problems, I thanked him for his time and stated that I would do my best to help. Thus, we started to communicate seamlessly with Emre and the backend team.

I added the structure we used to check PRs and issues on the frontend to the backend repository with small edits to monitor PRs and issues. The checkforce team was now monitoring both the frontend and backend repositories and closing invalid issues and PRs.

A special category was opened on the server for backend and related teams to work in a focused manner.

Alignment

Although there were tensions and separations between the teams, there were issues that we should not separate from each other. Our priority was to focus on how our applications could help save the lives of earthquake victims.

Personally, I have to say that I have never been so passionate about software development in my life. My new mission was to bring all the teams at Disaster Map into communication and alignment.

Since we had already shaken hands with Emre and moved forward together, the teams began to collaborate easily.
With short meetings, we produced solutions together to the obstacles encountered by both sides and were eagerly awaiting the new API endpoint. During the waiting period, I frequently joined the voice channels of the frontend team to assist with PRs and issues.

Legal issues

To ensure that we act in compliance with the law, I quickly added the Privacy Agreement, Data Sources, and Cookie Policy to the footer section. Documents prepared by lawyers on our server

Bottleneck problem

The fact that the data returned by the current API was large and not prepared as we had planned was a significant problem for the users. It seemed that fetching too much data at once and printing it to the user's browser could cause serious bottleneck problems.

We came up with 4 solutions to this.

Default to show the map at a higher zoom level to reduce the number of pins on the screen.
Load pins dynamically based on the user's position and the map viewport.
Provide a filter mechanism to allow users to select specific types of pins to display.
Enable pagination to limit the number of pins displayed on a single page.

Thanks to every hero who contributed, we succeeded in all of our endeavors. Maybe it's because I didn't see what the volunteers on the other side did, but the rational solution that Umut brought in for the drowning problem caused by clustering on the map, after working tirelessly for hours, really saved the day and left me in awe in every way possible. I hope he writes about it himself. Umut, you're a fantastic engineer!

Hold on for a minute! We can grow.

Although the backend and frontend teams are now working in a coordinated manner, I am aware that my area of expertise is not in product/project management and that many people are waiting to help in this regard. Therefore, I asked the moderators to direct me to someone who could help with the hiring process.

We started sharing job postings for a product manager and a frontend developer together because we needed more support. The new frontend developers were welcomed and transferred by other frontend team leaders, and I transferred information to keep the product managers up-to-date.

My duties were helping to integrate product management tools into projec, act as a communication bridge between the backend/frontend team and product managers, and onboarding product managers for the Disaster Map.

After a while I added new rules to our work routine.

Approved: No work should start until product managers approve the issues on GitHub. Product managers would prioritize the issues opened in the repositories and plan the development processes. This way, no one in the development team would work unnecessarily, and their efforts would not be wasted. Also, we would control the direction the product was going.
Although there were minor incompatibilities at the beginning, developers and product managers started to collaborate in a short time.

But wait a minute! Testing?

Another transfer I made to the product managers was that new features and the test environment on the frontend should be tested first. At this point, it was time to bring the waiting test experts on the server into work and be in contact with the test team manager.

I added two more labels to GitHub regarding testing, tested, and test-failed.

As a result, PRs were not merged without being tested by test experts in the preview screens provided by Vercel.

One more second. Design?

I have to mention that the designer colleagues on the server have designed a user interface before we went live, without forgetting to convey my greetings to all of them.

However, as we were using a ready-made library, we could not go beyond using the design they created as a sketch, thinking that customizing it would take too much time.

Our lack of communication from the beginning had brought us to a separate working point for a while. However, it was time to unite and accept the valuable help of the designers in order not to create a worse user interface.

I added an UI/UX tag so that product managers could add it if an open issue needed a design and designers could follow the process. This way, everyone would be informed when a design was expected for an issue.

Disaster Map organized, but?

Communication between the Backend, Cloud, and Data teams was already naturally provided. Thanks to the category organization we have on Discord, the Design, Test, Backend, Frontend, Cloud, Security, and Data teams were working connected and informed.

I had no idea of what other applications were being built. To be able to support the processes and get further information, I asked Eser, whom I had known before and saw as a role model and leads everyone in discord, if he could host me in his house during the process.

Eser hosted me as a guest at his home for a week, and his approach to topics and people in the processes I witnessed influenced my perspective on life. I saw him unable to eat the meal he ordered 8 hours ago because of the meetings. Yet still not complaining at all. He listened carefully and tried to respond to everyone he made video conference.

Synchronizing with Eser and exchanging ideas has immensely contributed to my ability to gain a comprehensive understanding, increase coordination, and establish closer communication with users and NGOs despite the challenges faced in the field.

144 Hours: It's not over yet

With the new API written in Go on the back end, the speed problem had been overcome, and a highly optimized system had been established. Things seemed to be going well. However, for the earthquake victims, nothing had ended. On the contrary, it was just beginning. We had to shape the product and add data according to the need.

New data available

We continued to add help, support, and search and rescue calls shared/made/published by non-governmental organizations, associations, aid organizations, press and media organizations, and public institutions and organizations to the API and the map to provide a more comprehensive interface and support.

Ahbap Locations

Hospitals

Hot Meal Points

New features

Multiple languages: Although our application does not use many language features, we added English language support in case teams coming from abroad may use it.

Map settings: We added satellite and terrain options, considering that there may be places where roads are in bad condition and unrecognizable.

Filtering: Time filtering and the addition of data verified by reliable sources made notifications filterable.

Is social media a weapon?

We had already learned things that would make hope sprout within us and ease our conscience a little. Volunteers called coordinators from the field and thanked us, saying that they used the application and gave feedback. This situation fueled us even more.

What was important on the technical side was that everyone using the product had to know that it was constantly being worked on and many people were working to provide a service.

Although AYA's social media teams continued to work for afetharita.com, we started to make announcements on social media because we knew the importance of every passing minute.

Everyone supported the posts to ensure that afetharita.com was heard by the field teams and earthquake victims. At this point, we saw that valuable figures like Memet Ali Alabora reported bugs and made social media posts to support us in the Discord server.

Week One

We knew that afetharita.com was being used. We knew that it gave hope to people. We knew that it received millions of requests and provided help.

People using disaster map on hospital

We knew that we needed to continue developing the application. I think everyone knew that. So much so that a helpful friend from abroad had prepared a map showing the donation points and details in Berlin and reached out to me to add it to afetharita.com, instead of directly adding it to the disaster map, I decided to redirect afetharita.com/berlin domain to it.

Later, afetharita.com/london and afetharita.com/netherlands joined our efforts.

Moreover, we added new data to the map

Filtering by need: We added filtering by intent with the help of the artificial intelligence model that our friends working in the background started to distinguish aid calls by need to make it easier to use. We immediately added improvements to the interface.

In addition to the map being heard on all social media, some people also added Disaster Map as an iframe module - without data or system sharing - to their projects to help reach more people.

Foreign media outlets such as Yahoo, Euronews, Wired and Time talked about Disaster Map.

We received great feedbacks from volunteers using the application.

Disaster map, which we provided as a free service about 30 hours after the earthquake disaster, had become a very effective tool in just its first week. Although I was proud of the work we did together, I was experiencing mixed feelings as I empathized.

Individually, the things i learned are priceless I had the opportunity to be a part of a project that I probably wouldn't see another example of in my life and meet amazing people.

I learned that ideas and impact could be more important than titles, how important communication skills could be under stress, how effective teamwork could be, and how helping someone else could speed up things... Love and solidarity.

Caner Akın, a Product Manager at GHD with whom I worked and established an interesting bond, expressed his feelings with these beautiful sentences on his LinkedIn profile.

These nine days were like nine years. We went through such a period that we became 40-year-old friends. We fought, apologized, and mourned together. We worked together day and night. We cried with our brother who found out that his relative's body had been found at dawn. We said, "Just one more day," and continued. The most important thing was this: we were proud. Knowing that we had people we could rely on made us proud. The fact that people who said, "As long as one more life is saved with a pure heart without any expectations," were together in Disaster Map made us feel that we were not alone and hopeless.

Among the products developed under the Açık Yazılım Ağı, it served as the flagship, and although I have only spoken and shared my experiences about it specifically for afetharita.com so far, there are many applications in the background that receive millions of traffic and provide software support to earthquake victims.

For more detailed information about these applications, you can visit afet.org.
All repositories are collected publicly under the Açık Kaynak organization on GitHub.

Week 2

As we had aimed, Disaster Map had provided its support during the emergency and critical days of the earthquake, and had gained public attention.

In fact, NBC broadcasted about Disaster Map.

After a period of more than 10 days, as necessary awareness and aid began to be delivered across the country both at the volunteer and public level, we felt the need to determine a new roadmap.

Today: Our roadmap

For Açık Yazılım Ağı, it's time to destroy personal and sensitive data within the scope of the Personal Data Protection Law.

For Disaster Map, in the first stage, it continues to provide service with only verified and non-personal information. In the near future, we are going to continue adding useful features to Disaster Map with more planned user interface design behind the scenes but afetharita.com will be completely closed to usage and requests will be directed to afet.org.

This may sound like bad news, but it's actually not, because now we are closer to my imaginary goal that came to my mind on the fourth day. "This application should be turned into a program that can be downloaded and installed end to end, and should be available for customization and use in any disaster situation, offering free service to the whole world."

Final words and a message for the world

We cannot stress enough the importance of having tools like afetharita.com available during times of crisis and urge you to take action and support this project so that it is ready and available for those who need it most.
This project was born from the tireless efforts of volunteers and the generosity of small donors.
However, to ensure its continued success and fulfillment of its objectives, we humbly request your support.
Established international organizations with experience in supporting similar initiatives are particularly encouraged to assist us.
Please note that support can come in various ways. This disaster is not limited to Turkey and the product produced will have global significance.
To contact for collaboration send a mail with "afetharita" subject: eray@gundogmus.dev

Other useful links

Afet.org
Frontend Repository
Backend Repository
Special thanks to Merve Noyan and AI, NLP and ML teams...
Machine Learning Models

DEV Community: Eray Gündoğmuş

Build a Multilingual Next.js App in 5 Minutes with App Router

TL;DR

What You Get

Quick Start

How It Works

Config (i18n.config.ts)

Middleware (middleware.ts)

Layout (src/app/[locale]/layout.tsx)

Customization

Add a new language

Add a new page

Deploy to Vercel

Links

Best i18n Libraries for Next.js, React & React Native in 2026 (Honest Comparison)

TL;DR — Quick Comparison Table

How We Evaluated

1. Better i18n

Key Features

Code Example (Next.js App Router)

When to Choose Better i18n

When NOT to Choose Better i18n

Pricing

2. next-intl

Code Example

Strengths

Limitations

When to Choose

3. react-i18next

Code Example

Strengths

Limitations

When to Choose

4. LinguiJS

Code Example

Strengths

Limitations

When to Choose

5. Paraglide (by Inlang)

Strengths

Limitations

When to Choose

6. FormatJS (react-intl)

Strengths

Limitations

When to Choose

7. Intlayer

Strengths

Limitations

When to Choose

8. typesafe-i18n

Strengths

Limitations

When to Choose

Decision Framework

Performance Benchmarks

The Takeaway

Scaling i18n Beyond Lazy Loading: What Framework Comparisons Miss About Real-World Localization

The framework comparison trap

Problem 1: The namespace illusion

The namespace decision tax

The cross-namespace import problem

What actually works

Problem 2: The merge conflict multiplier

What actually works

Problem 3: The ghost key problem

Why regex-based detection fails

What actually works: AST scanning

Problem 4: The 47-minute typo fix

What actually works: CDN-decoupled translations

Problem 5: The context black hole

What reduces this

Problem 6: The type safety gap

What actually works

The real scaling checklist

The migration is not the hard part

What I'd recommend today

How I Set Up i18n in My React/Next.js App Without Losing My Mind

The problem nobody warns you about

My setup (and why I chose it)

Config (`i18n.config.ts`)

Middleware (`middleware.ts`)

Layout (`src/app/[locale]/layout.tsx`)