Terug naar het blog

Lege vertaalde blogposts bij manifest-gebaseerde implementatie

2025-10-072 min read

Het Probleem

Na de implementatie op Cloudflare laadden vertaalde blogposts (Spaans, Duits, Frans, etc.) willekeurig met lege inhoud. Soms werkten ze prima, soms niet. De pagina werd weergegeven, maar de inhoud ontbrak.

Wat is een Manifestbestand?

Mijn blogposts worden opgeslagen als JSON-bestanden in de codebase, niet in een database. Hierdoor kan ik inhoud schrijven in mijn editor en alles volgen in Git. Simpel.

Een manifestbestand is een vooraf gegenereerd JSON-bestand dat alle blogpostgegevens bevat. Cloudflare Workers hebben tijdens runtime geen toegang tot een traditioneel bestandssysteem; ze kunnen alleen bestanden gebruiken die tijdens de build zijn gebundeld. Dus in plaats van tijdens runtime individuele blogpostbestanden te lezen, maakt het buildproces één manifest met alle posts.

Het manifest wordt gegenereerd tijdens de buildtijd en opgenomen in de implementatie. Tijdens runtime leest de code uit dit manifest in plaats van uit het bestandssysteem.

De Oorzaak

Mijn manifeststructuur ziet er als volgt uit:

{
"slug": "mijn-post",
"translatedSlugs": {
"en": "my-post",
"es": "mi-publicacion"
},
"localized": {
"es": { "title": "...", "content": "..." },
"de": { "title": "...", "content": "..." }
}
}

Let op: Engels zit NIET in het localized object. Engelse inhoud bevindt zich op het basisniveau.

Mijn getPostByTranslatedSlug functie deed het volgende:

// Haal de post op met de Engelse locale om translatedSlugs te benaderen
const post = getPostBySlug(slug, 'en');

// Controleer of translatedSlugs overeenkomen...
if (post.translatedSlugs[someLocale] === translatedSlug) {
return getPostBySlug(slug, requestedLocale);
}

Toen ik getPostBySlug(slug, 'en') aanriep, probeerde het manifest.localized.en te benaderen, wat niet bestaat, en retourneerde daarom lege inhoud.

De Oplossing

In plaats van getPostBySlug(slug, 'en') aan te roepen, heb ik dit gewijzigd om getAllPosts() te gebruiken, wat alle posts retourneert met basismetadata, inclusief translatedSlugs:

export function getPostByTranslatedSlug(translatedSlug: string, locale: string): BlogPost | null {
// Haal alle posts op om toegang te krijgen tot basismetadata
const allPosts = getAllPosts();

for (const post of allPosts) {
if (post.translatedSlugs) {
for (const [lang, slugValue] of Object.entries(post.translatedSlugs)) {
if (slugValue === translatedSlug) {
// Gevonden! Haal nu de gelokaliseerde versie op
return getPostBySlug(post.slug, locale);
}
}
}
}
return null;
}

Is het Gebruik van een Manifestbestand een Goede Praktijk?

Het hangt af van uw implementatiedoel:

Voor Cloudflare Workers / Edge-platforms: Ja, het is noodzakelijk. Deze platforms hebben geen toegang tot een traditioneel bestandssysteem, dus u moet alle gegevens bundelen tijdens de build.

Voor traditionele Node.js-servers (Vercel, AWS, etc.): Niet vereist. U kunt tijdens runtime uit het bestandssysteem lezen, wat eenvoudiger is en geen buildstap vereist om het manifest te genereren.

De afweging: manifestbestanden voegen complexiteit toe aan uw buildproces en kunnen fouten zoals deze veroorzaken als ze niet zorgvuldig zijn gestructureerd. Maar ze maken implementatie op edge-platforms mogelijk, die sneller en goedkoper zijn.

Geleerde Les

Bij het gebruik van een manifest voor statische exports:

  • Ga er niet van uit dat de basislocale bestaat in localized
  • Basismetadata (zoals translatedSlugs) bevinden zich op het hoofdpad
  • Alleen niet-basis-locales staan in localized

Blijf op de hoogte

Ontvang de nieuwste berichten en inzichten in je inbox.

Unsubscribe anytime. No spam, ever.