Next.js ile Sunucusuz, Çok Dilli Statik Web Sitesi Oluşturma
Next.js ile Sunucusuz Çok Dilli: Next.js iddiası ne anlatıyor? Next.js ile Sunucusuz Çok Dilli kapsamında, Geçen ay işlettiğim küçük bir web sitesini yeniden oluşturdum. Cloudflare Sayfalarında barındırılan sekiz dilde statik dışa aktarma; ücretsiz, hızlı ve yama…
Next.js ile Sunucusuz Çok Dilli: Next.js iddiası ne anlatıyor?
Next.js ile Sunucusuz Çok Dilli kapsamında, Geçen ay işlettiğim küçük bir web sitesini yeniden oluşturdum. Cloudflare Sayfalarında barındırılan sekiz dilde statik dışa aktarma; ücretsiz, hızlı ve yama gerektirmiyor. İşin püf noktası: statik dışa aktarma ve i18n birbirleriyle savaşmaz, ancak birkaç şey hakkındaki düşüncelerinizi değiştirirler. İşte sonunda bulduklarım ve ilk başta belli olmayan kısımlar.
Next.js ile Sunucusuz Çok Dilli kapsamında, Next.js 15 yığını, next-intl 4, React 18 ile birlikte, tümü çıktıyla önceden işlendi: ‘export’. Ara yazılım yok, sunucu işlevi yok. Her sayfa, oluşturma sırasında gerçek bir HTML dosyasına dönüşür.
Next.js ile Sunucusuz Çok Dilli kapsamında, // next.config.js ‘next-intl/plugin’den { withNextIntl } dosyasını içe aktarın; const sonrakiYapılandırma = { çıktı: ‘dışa aktar’, resimler: { optimize edilmemiş: doğru }, }; varsayılanı dışarı aktar withNextIntl(nextConfig); Images.unoptimized bayrağı, statik dışa aktarmanın görüşlere sahip olduğunun ilk ipucudur.
Tasarım ve teknik ayrıntılar
Next.js ile Sunucusuz Çok Dilli kapsamında, Sunucu olmadığında görüntü hattı da yoktur, bu nedenle next/image’e dosyaları yalnız bırakmasının söylenmesi gerekir. İstekten değil URL’den yerel ayar Bir sunucuda genellikle Accept-Language okursunuz ve istek başına bir yerel ayar seçersiniz. Statik dışa aktarmada inceleme isteği yoktur. Yerel ayarın URL’nin kendisinden gelmesi gerekir ve her yerel ayarın önceden oluşturulmuş ayrı bir dosya kümesi olması gerekir.
Next.js ile Sunucusuz Çok Dilli kapsamında, Yönlendirmeyi kasıtlı bir seçimle tanımladım: // src/i18n/routing.ts ‘next-intl/routing’den { defineRouting }’i içe aktarın; const yönlendirmeyi dışa aktar = defineRouting({ yerel ayarlar: [‘en’, ‘de’, ‘ja’, ‘ko’, ‘es’, ‘fr’, ‘pt’, ‘it’], defaultLocale: ‘tr’, yerel ayarÖneki: { mod: ‘her zaman’, önekler: { en: ” }, }, }); mode: ‘her zaman’ normalde her URL’nin kendi yerel ayarını (/de/team, /ja/quiz) taşıdığı anlamına gelir.
Next.js ile Sunucusuz Çok Dilli kapsamında, Önekler: { en: ” } satırı bir istisna oluşturur: İngilizce herhangi bir önek almaz, bu nedenle /team ve /quiz’de bulunurken diğer her şey kendi dil kodunu korur. Neden zahmet edeyim ki? İki sebep. İngilizce birincil kitledir, bu nedenle temiz URL’ler biraz ekstra yapılandırmaya değer.
Bugünden bakınca ne kadar güvenilir?
Ve aynı içeriğe işaret eden iki (/team ve /en/team) yerine sayfa başına bir kanonik URL tutar; bu da tam olarak Google’ın sayfalarınızı kopya olarak görmesine neden olan türden bir şeydir. Yerel ayarın next-intl ön işlemesine bağlanması normalde yerel ayarı ara yazılımda algılar. Statik dışa aktarmada ara katman yazılımı hiçbir zaman çalışmaz; ana bilgisayar yalnızca dosyaları sunar.
Bu nedenle yerel ayarın rota segmenti üzerinden manuel olarak yapılması gerekiyor: // src/i18n/request.ts ‘next-intl/server’dan { getRequestConfig }’i içe aktarın; ‘./routing’ dosyasından { routing } dosyasını içe aktarın; varsayılanı dışa aktar getRequestConfig(async ({ requestLocale }) => { let yerel ayar = requestLocale bekleniyor; if (!locale || !routing.locales.includes(locale)) { yerel ayar = routing.defaultLocale; } dönüş { yerel ayar, saat dilimi: ‘UTC’, mesajlar: (içe aktarmayı bekliyor(`../messages/${locale}.json`)).varsayılan, }; }); Buradaki requestLocale, bir başlıktan değil, uygulama yönlendiricisindeki [locale] dizininden gelir.
Mesajlar, src/messages/ altında dil başına düz JSON olarak yayınlanır ve derleme aşamasında statik olarak yüklenir Ben. Çalışma zamanında dinamik içe aktarma yok, paketleme sürprizleri yok. Gözden kaçması kolay kritik bir nokta var: Next.js’ye hangi yerel ayar yollarının önceden oluşturulacağını söylemeniz gerekiyor.
Okuyucu için pratik anlamı
app/[locale]/layout.tsx altındaki kök düzende createdStaticParams’ın yaptığı da budur: // src/app/[locale]/layout.tsx { yönlendirme }’yi ‘@/i18n/routing’ adresinden içe aktarın; dışa aktarma işlevi createdStaticParams() { return routing.locales.map((locale) => ({ locale })); } Bu, her dilin derleme sırasında statik HTML dosyalarından oluşan kendi klasörünü almasını sağlar.
Kaçırırsanız yalnızca varsayılan yerel ayarı alırsınız. Daha sonra her sunucu bileşeni setRequestLocale(locale) öğesini çağırır, böylece sayfanın meta verileri ve içeriği hangi dili oluşturduklarını bilir. Bu çağrıyı kaçırırsanız bir derleme hatasıyla karşılaşırsınız ki bu gerçekten bir özelliktir; bu, yerel ayarın asla sessizce yanlış olmadığı anlamına gelir.
SEO açısından kritik kısım: hreflang Özellik başına sekiz neredeyse aynı sayfa, Google’ın bunların birbirinin kopyası değil çevirisi olduğunu bilmesi için yardıma ihtiyacı olduğu anlamına gelir. Hreflang bunun için var ve bunu doğru yapmak, bu konuda gerçekten çaba harcamamın ana nedeniydi.
// src/lib/seo.ts const ALAN = ‘https://pokemongen.com’; const LOCALES = [‘en’, ‘de’, ‘ja’, ‘ko’, ‘es’, ‘fr’, ‘pt’, ‘it’]; dışa aktarma işlevi alternatifleri (yol: dize, yerel ayar: dize) { const cleanPath = yol === ‘/’ ? ” : yol; sabit kanonik = yerel ayar === ‘en’ ? `${DOMAIN}${cleanPath}` : `${DOMAIN}/${locale}${cleanPath}`; dönüş { kanon ical, diller: { …Object.fromEntries( LOCALES.map((l) => [l, l === ‘tr’ ?
`${DOMAIN}${cleanPath}` : `${DOMAIN}/${l}${cleanPath}`]) ), ‘x-default’: `${DOMAIN}${cleanPath}`, }, }; } Bu, Next’in alternatif meta veri alanını besler, böylece önceden oluşturulmuş her sayfa standart bir etiket artı sekiz dilin her biri için bir ve İngilizce URL’yi gösteren bir x-default ile sonuçlanır. x-default insanların atladığı şeydir.
Eşleşen dili (veya tarayıcısı) olmayan bir kullanıcının ulaşmasını istediğiniz şey budur. İngilizceye işaret ediyorum. Eğer unutursanız, Google’ın tahmin etmesi gerekir ve yeterince sıklıkla yanlış tahminde bulunur, bu da ekstra satıra değecektir. Sorunun diğer yarısı, yalnızca sayfa gövdesinin değil, meta verilerin de çevrilmesi gerekmesidir.
Başlık, açıklama ve OpenGraph etiketlerinin tümü aynı JSON dosyalarındaki dizelerdir ve her yerel ayara göre alınır.
İşte hepsini birbirine bağlayan bir yardımcı: // src/lib/page-helpers.tsx ‘next-intl/server’dan { getTranslations, setRequestLocale }’yi içe aktarın; ‘@/lib/seo’dan { alternatifleri } içe aktarın; dışa aktarma işlevi makePageMetadata({ ad alanı, yol }: { ad alanı: dize; yol: dize }) { eşzamansız işlevi döndür createdMetadata(locale: string) { setRequestLocale(locale); const t = wait getTranslations({ locale, namespace }); dönüş { başlık: t(‘başlık’), açıklama: t(‘açıklama’), alternatifler: alternatifler (yol, yerel ayar), openGraph: { başlık: t(‘başlık’), açıklama iyon: t(‘açıklama’)}, }; }; } Ve bunu bir sayfada şu şekilde kullanabilirsiniz: // src/app/[locale]/page.tsx ‘@/lib/page-helpers’ adresinden { makePageMetadata } dosyasını içe aktarın; eşzamansız dışa aktarma işlevi createdMetadata({ params }: { params: { locale: string } }) { return makePageMetadata({ namespace: ‘home’, path: ‘/’ })(params.locale); } H1’de Almanca “Takım Oluşturucu” yazan ancak başlık etiketinde hala İngilizce “Takım Oluşturucu” yazan bir sayfa yaygın bir i18n hatasıdır.
Her ikisini de aynı mesaj ad alanında tutmak, her ikisinin de tercüme edeceği veya ikisinin de tercüme etmeyeceği anlamına gelir. Statik dışa aktarmanın ödünleri Dengeler gerçektir ve bu proje için hepsi iyiydi ancak listelenmeye değer: Sonraki/görüntü optimizasyonu yok. Daha önce de belirtildiği gibi – işaretlemeyi kaldırın, düz PNG’ler sunun. Çalışma zamanı yönlendirmesi veya yeniden yazma işlemi yok.
/pt’nin bir yere yönlendirmesini isteseydim, bunun Next config değil, Cloudflare Pages kuralı olması gerekirdi. Her yerel ayar fiziksel dosyalardır. Sekiz dil çarpı ancak birçok rota, yapının çok fazla HTML yaydığı anlamına gelir. Hizmet vermesi hızlıdır ancak 9. dil, tek satırlık bir yapılandırma değişikliği değil, bir karardır. Bulunamayan sayfaların da bir yerel ayara ihtiyacı vardır.
404 hala bir sayfadır, dolayısıyla [yerel] altında yaşar ve statik dışa aktarma, varsayılan sayfayı ana bilgisayar için 404.html ile eşler. Derlemenin kendisi küçük bir Node betiğidir: sonraki derlemeyi çalıştırın, ardından önceden oluşturulmuş HTML’yi yürütün ve Cloudflare Pages’ın beklediği gibi ///index.html olarak düzenleyin ve _not-found.html’yi 404.html ile eşleştirin.
Yazması yirmi dakika süren ve sizi daha sonra adaptörle uğraşmaktan kurtaran türden bir yapıştırıcıdır. ## Buna değer miydi? Statik, içerik odaklı bir araç sitesi için evet. Sayfalar anında yüklenir, barındırma gerçekten ücretsizdir ve hreflang kurulumu, arama motorlarının sekiz kopyayı birbirine göre sıralamak yerine aslında doğru dili doğru bölgeye sunması anlamına gelir. Dürüst olumsuz tarafı çevirilerdir.
Elle tutulan sekiz JSON dosyası sıkıcıdır ve içeriğiniz her hafta değişirse bu yaklaşım kendinizden nefret etmenize neden olur. Burada çalışıyor çünkü kopya çoğunlukla statik. Sitenizde sunucu tarafı özellikler veya kullanıcı hesapları yoğunsa, bunun yerine sunucu ve ara yazılım tabanlı yerel ayar tespitine yönelirsiniz; bu kurulum yalnızca tamamen statik olmayı göze alabildiğinizde kazanır.
pokemongen.com adresindeki canlı siteyi deneyebilirsiniz.
İlgili yazılar
- Sunucusuz Statik Sitelerinize Dinamik Özellikler Ekleyin
- Godot 4’te Karakter Hareketi İçin Görsel İzler Oluşturma
Ek okuma: MDN Web Docs
Editörün Notu
Next.js ile çok dilli statik siteler oluştururken, sunucusuz mimarinin avantajlarını kullanarak hızlı ve bakım gerektirmeyen çözümler geliştirebilirsiniz; özellikle i18n entegrasyonunda statik dışa aktarma yöntemlerini tercih etmek performansı artırır.
