Pola Thin Route + Shared Component buat Halaman Dwibahasa di Astro

Situs dwibahasa gampang berakhir dengan markup yang di-duplikat dua kali — sekali di /halaman.astro, sekali lagi di /en/halaman.astro — dan setiap perubahan desain harus diinget buat diterapin di dua tempat. Situs ini pakai pola berbeda dari awal dibangun: thin route + shared component, dan saya baru beneran sadar seberapa berharga pola ini pas ngalamin sendiri versi sebaliknya di proyek client.

Cara kerjanya: setiap halaman listing/detail (Home, Portfolio, Blog) punya satu component “body” yang locale-agnostic di src/components/pages/, misalnya BlogIndex.astro. Component ini nerima locale sebagai prop, ngambil dictionary lewat getDictionary(locale) buat semua teks chrome (label, judul section), dan manggil getBlogPosts(locale) buat data konten — nggak ada teks yang di-hardcode di mana pun.

Route file-nya sendiri jadi nyaris kosong. src/pages/blog/index.astro isinya cuma import component dan render <BlogIndex locale="id" />, sementara src/pages/en/blog/index.astro render <BlogIndex locale="en" />. Satu baris beda locale, sisanya sama persis. Pertama kali saya nulis pola ini, kerasa berlebihan buat halaman sesimpel ini — kok cuma buat render satu component doang perlu file terpisah? Tapi manfaatnya baru kerasa begitu situs ini nambah halaman.

Nggak semua halaman pakai pola ini, dan itu keputusan sadar. Halaman kayak About dan Contact sengaja saya kecualikan, karena isinya prose yang nggak berulang — bio saya di halaman About nggak punya struktur berulang kayak dictionary chrome, jadi lebih masuk akal ditulis langsung per file per bahasa daripada dipaksa masuk sistem dictionary yang dirancang buat label pendek yang berulang. Maksain semua halaman lewat satu pola yang sama itu jebakan yang saya coba hindari — konsistensi struktural yang dipaksain malah bikin kode lebih ribet, bukan lebih rapi.

Manfaat nyatanya baru beneran saya rasain pas ngerjain proyek client yang nggak pakai pola ini — markup-nya dobel dari awal antara dua versi bahasa. Klien minta ubah layout satu kartu produk, dan developer sebelumnya (bukan saya yang bangun awalnya) cuma update versi bahasa Inggrisnya doang, lupa versi lainnya. Nggak ketahuan sampai QA nemu inkonsistensi visual dua minggu kemudian. Balik ke situs saya sendiri, kalau saya ubah layout kartu blog post, saya cukup edit satu file (PostCard.astro, dipanggil dari BlogIndex.astro), dan otomatis konsisten di kedua bahasa — nggak ada kemungkinan lupa nerapin di tempat kedua, karena tempat keduanya nggak ada.

Pola ini bukan sesuatu yang canggih secara teknis — ini cuma disiplin pemisahan concern yang konsisten, hal yang sebenernya udah lama diajarin di software engineering jauh sebelum Astro ada. Tapi disiplin kecil kayak gini yang bikin situs dwibahasa tetep gampang di-maintain seorang diri, tanpa checklist mental “jangan lupa update versi satunya” tiap kali ngubah sesuatu.