Monorepo for CodeDay's web applications and shared packages.

pnpm install
pnpm run build

The monorepo has two independent localization layers. Both are provided by shared packages so any app in the monorepo can use them.

Translations are powered by Paraglide JS. Message files live in packages/i18n/messages/{locale}.json. Keys are prefixed by package — topo_* for design-system strings, www_* for app strings.

URL structure: Every page URL includes a locale prefix — /en/about, /es/about. If a user visits a bare path like /about, middleware detects the browser's preferred language and redirects.

import * as m from "@codeday/i18n/messages";

function Footer() {
  return <p>{m.topo_footer_copyright({ currentYear: "2026" })}</p>;
}

Client-side (React components):

import { getLocale } from "@codeday/i18n/runtime";

const locale = getLocale(); // "en" | "es"

Server-side (getStaticProps / getServerSideProps):

import { getLocaleFromContext } from "@codeday/i18n/next-pages";

export const getStaticProps: GetStaticProps = async (ctx) => {
  const locale = getLocaleFromContext(ctx);
  // ...
};

To use m.*() inside data-fetching functions, wrap with the locale helper:

import { withLocaleStaticProps } from "@codeday/i18n/next-pages";
import * as m from "@codeday/i18n/messages";

export const getStaticProps = withLocaleStaticProps(async (ctx) => {
  return { props: { title: m.page_title() } };
});

1. Add the locale code to packages/i18n/project.inlang/settings.json → locales
2. Create packages/i18n/messages/{locale}.json with translated values
3. In each app: add the locale to next.config.ts → i18n.locales and AVAILABLE_LOCALES in middleware.ts

Region codes are resolved from the top-level domain the visitor is using. This is independent of UI language — a user on codeday.fr gets region eu but can still view the site in English.

@codeday/topo/Region ships a built-in TLD_REGION_MAP:

Apps can pass an optional overrides map to add new TLDs or override specific full domain names.

1. In middleware, resolve and forward the region as a header:

import { getRegionFromHostname, REGION_HEADER } from "@codeday/topo/Region/config";

// inside middleware():
const region = getRegionFromHostname(request.headers.get("host"));
const headers = new Headers(request.headers);
headers.set(REGION_HEADER, region);
return NextResponse.next({ request: { headers } });

2. In _app.tsx, wrap with <RegionProvider>:

import { RegionProvider, getRegionFromHostname } from "@codeday/topo/Region";

const region = useMemo(
  () => getRegionFromHostname(typeof window !== "undefined" ? window.location.hostname : undefined),
  [],
);

return <RegionProvider value={region}>...</RegionProvider>;

Pass an overrides map to getRegionFromHostname. Full-domain keys take priority, then override TLD keys, then the built-in TLD_REGION_MAP.

const overrides = { "staging.codeday.org": "eu", "dev": "us" };
const region = getRegionFromHostname("staging.codeday.org", overrides); // "eu"

Client-side (React components):

import { useRegion } from "@codeday/topo/Region";
const region = useRegion(); // "us" | "eu" | "uk" | ...

Server-side (getServerSideProps):

import { getRegionFromContext } from "@codeday/topo/Region";

export const getServerSideProps: GetServerSideProps = async (ctx) => {
  const region = getRegionFromContext(ctx);
  return { props: { region } };
};

getRegionFromContext only works with getServerSideProps (it reads request headers). In getStaticProps there is no request — use getRegionFromHostname() with a known hostname, or resolve the region client-side.

Add an entry to TLD_REGION_MAP in packages/topo/src/Region/config.ts. No other files need to change.

• _default locale sentinel — Next.js Pages Router requires a defaultLocale. We use _default so that bare paths are detectable by middleware (otherwise they'd be silently served as English). Middleware redirects _default to the browser's preferred language.
• @codeday/topo/Region/config vs @codeday/topo/Region — Middleware runs in the Edge runtime, which cannot import React or Node.js built-ins. The /config module is kept dependency-free so both middleware and the full app can use it.