Building a Global, Multilingual Memorial Site with Next.js 15 on Cloudflare — What I Learned

pengcheng zhao — Thu, 30 Jul 2026 18:39:36 +0000

A stray dog named Wangwang touched people around the world. What started as a small, personal act of remembrance grew into a multilingual digital memorial — a quiet, hopeful space where anyone can leave a message, light a candle, and stand up for animal welfare.

I built it as a side project, but shipping it taught me a lot about deploying Next.js 15 to the edge, client-side i18n that actually works, and SEO hygiene. This post walks through the architecture and the gotchas, in case you're building something similar.

Note: I won't paste any secrets here. Cloudflare bindings (D1 id, R2, PayPal keys) live in wrangler.toml and stay out of this post.

The stack
Next.js 15 + React 19, TypeScript
Tailwind CSS 3.4
OpenNext to deploy on Cloudflare Workers (@opennextjs/cloudflare)
Cloudflare D1 (SQL database for messages) + R2 (user-uploaded images)
react-simple-maps + d3-geo + topojson-client for the interactive world map
7 languages: zh-CN, zh-TW, en, hi, es, fr, ar (with right-to-left support)
Deploying Next.js to Cloudflare Workers with OpenNext
This was the part with the most surprises. Next's default next build produces output tuned for Node servers or Vercel. To run it on Cloudflare's edge runtime, OpenNext repackages the app into a Worker.

My wrangler.toml wires up the Worker entry, static assets, and the two bindings:

name = "wangwang-memorial"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat"] # React 19 / Next need Node APIs
main = ".open-next/worker.js"

[assets]
directory = ".open-next/assets"

Cloudflare D1 (messages DB) and R2 (uploaded images).

Real ids/secrets are kept out of source control / this post.

[[d1_databases]]
binding = "DB"
database_name = "wangwang_db"
database_id = ""

[[r2_buckets]]
binding = "R2_BUCKET"
bucket_name = "wangwang-images"

[vars]
NEXT_PUBLIC_PAYPAL_CLIENT_ID = ""
R2_PUBLIC_URL = ""

routes = [
{ pattern = "wangwangdog.org", custom_domain = true },
{ pattern = "www.wangwangdog.org", custom_domain = true },
]
The deploy commands come straight from package.json:

"preview": "opennextjs-cloudflare build && opennextjs-cloudflare preview",
"deploy": "opennextjs-cloudflare build && opennextjs-cloudflare deploy"
Gotcha #1: SSG 404s on dynamic routes
On Cloudflare, my dynamic blog routes (/blog/[slug]) sometimes returned 404 because the edge cache expected pre-rendered HTML that wasn't there. The fix was to force on-demand rendering for those routes:

// src/app/blog/[slug]/page.tsx
// Force the Worker to render per-request (SSR) instead of relying on
// pre-rendered static HTML that may be missing on Cloudflare.
export const dynamic = "force-dynamic";
Pages that are truly static (the marketing pages) are left alone; only the data-driven ones opt into force-dynamic. Net result: no more missing pages, and the DB-backed content stays fresh.

Client-side i18n that survives hydration
I went with a lightweight client-side dictionary rather than Next's heavier routing-based i18n. A single translate(lang, key) function reads from a per-language dictionary, and a React context exposes it:

// src/lib/i18n.ts (excerpt)
export type Lang = "zh-CN" | "zh-TW" | "en" | "hi" | "es" | "fr" | "ar";
export const DEFAULT_LANG: Lang = "zh-CN";
// ...a dictionary per language, e.g. { "nav.home": "首页", ... }
The provider keeps the choice in localStorage and — importantly — sets the document direction so Arabic renders RTL:

// src/components/I18nProvider.tsx (excerpt)
useEffect(() => {
const el = document.documentElement;
el.lang = lang;
el.dir = lang === "ar" ? "rtl" : "ltr"; // ← easy to forget, critical for Arabic
}, [lang]);
The trick to avoid hydration mismatches: start with the default language on the server, then read the saved language in a useEffect after mount. That way server and first client render agree, and the switch happens a frame later.

SEO: complete Open Graph + Twitter cards
Search and social previews were broken by default — child pages inherited the homepage's OG title and had no share image. I centralized everything in one buildMetadata() helper so every page gets a correct title, description, canonical URL, OG block, and Twitter card:

// src/lib/seo.ts (excerpt)
export function buildMetadata({
title, description, path, image,
}: {
title: string;
description: string;
path: string;
image?: string;
}) {
const url = ${SITE_URL}${path};
return {
title,
description,
alternates: { canonical: url },
openGraph: {
title, description, url,
siteName: SITE_NAME,
locale: "zh_CN",
type: "website",
images: [{ url: image ?? DEFAULT_OG_IMAGE, width: 1200, height: 630 }],
},
twitter: {
card: "summary_large_image",
title, description,
images: [image ?? DEFAULT_OG_IMAGE],
},
};
}
And the root layout declares metadataBase so Next resolves absolute OG URLs without warnings:

export const metadata = {
metadataBase: new URL(SITE_URL),
title: { default: "Remember Wangwang", template: "%s | Remember Wangwang" },
// ...openGraph + twitter filled in via buildMetadata for each route
};
Gotcha #2: canonical domain with a 301
To avoid duplicate-content penalties between www and the apex domain, a tiny middleware does a permanent redirect:

// src/middleware.ts (excerpt)
const WWW_HOST = "www.wangwangdog.org";
const APEX_HOST = "wangwangdog.org";

export function middleware(request: NextRequest) {
const host = request.headers.get("host")?.toLowerCase() ?? "";
if (host === WWW_HOST) {
const url = request.nextUrl.clone();
url.host = APEX_HOST;
return NextResponse.redirect(url, 301);
}
return NextResponse.next();
}

// Run only on pages, skip static assets & _next internals
export const config = {
matcher: "/((?!api|_next/static|_next/image|favicon.ico|.\.).)",
};
The interactive world map
The "Global Voices" page plots where messages come from. react-simple-maps makes this painless on top of d3-geo projections and a TopoJSON world file:

{({ geographies }) =>
geographies.map((geo) => )
}

{markers.map((m) => (

))}

Because it's all SVG, it stays crisp on any screen and works without a heavy mapping dependency.

What I'd tell my past self
force-dynamic is your friend on Cloudflare for DB-backed, on-demand content — don't fight the edge cache.
Set el.dir for RTL languages the moment you add Arabic/Hebrew; it's a one-liner that's easy to skip.
Centralize SEO metadata. A single buildMetadata() beats copy-pasting OG tags per page and prevents the "all shares show the homepage title" bug.
301 your canonical domain early — fixing it after indexing is annoying.
Keep secrets in wrangler.toml / env vars, never in blog posts or client bundles.
Try it
The site is live at wangwangdog.org. If you've shipped a Next.js app to Cloudflare (or fought with i18n), I'd love to hear how you approached it in the comments.

Happy to share more code snippets or the full wrangler.toml structure if there's interest.

DEV Community: pengcheng zhao

Building a Global, Multilingual Memorial Site with Next.js 15 on Cloudflare — What I Learned

Cloudflare D1 (messages DB) and R2 (uploaded images).

Real ids/secrets are kept out of source control / this post.