@intlayer/docs 8.9.4 → 8.9.5

package/docs/ru/plugins/sync-po.md

@@ -160,30 +160,9 @@ syncPO({
   source: ({ key, locale }) => string, // обязательно
   location?: string, // необязательная метка, по умолчанию: "sync-po::path/to/source"
   priority?: number, // необязательный приоритет для разрешения конфликтов, по умолчанию: 0
-  format?: 'icu' | 'i18next' | 'vue-i18n', // необязательно, требуется только если значения msgstr используют специфический синтаксис интерполяции
 });
 ```
 
-#### `format` ('icu' | 'i18next' | 'vue-i18n')
-
-PO-файлы — это всегда файлы Gettext Portable Object, это фиксировано. Этот параметр описывает только **синтаксис интерполяции**, используемый внутри значений `msgstr`, чтобы Intlayer мог преобразовать их в свой собственный формат во время разбора (через `formatDictionary`) и обратно при записи вывода.
-
-- `undefined` _(по умолчанию)_: значения `msgstr` обрабатываются как обычные строки — без преобразования. Используйте это для большинства PO-файлов.
-- `'icu'`: значения `msgstr` используют синтаксис сообщений ICU (например, `{count, plural, one {# item} other {# items}}`).
-- `'i18next'`: значения `msgstr` используют синтаксис интерполяции i18next (например, `{{variable}}`).
-- `'vue-i18n'`: значения `msgstr` используют синтаксис Vue I18n.
-
-> Преобразование применяется функцией `formatDictionary` плагина `@intlayer/chokidar` при загрузке и обращается функцией `formatDictionaryOutput` при записи. Для сложных правил, таких как множественное число ICU, точность обратного преобразования не гарантируется.
-
-**Пример — PO-файлы содержат интерполяцию в стиле i18next:**
-
-```ts
-syncPO({
-  source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
-  format: "i18next",
-}),
-```
-
 ### Несколько источников PO и приоритет
 
 Вы можете добавить несколько плагинов `syncPO` для синхронизации различных источников PO. Это полезно, когда у вас есть несколько источников перевода или различные структуры PO в вашем проекте.

package/docs/tr/benchmark/index.md

@@ -30,6 +30,3 @@ Her çatı için ayrıntılı raporlar ve teknik belgeleri aşağıda bulabilirs
 - [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
 - [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
 - [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)
-- [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
-- [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
-- [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)

package/docs/tr/benchmark/nextjs.md

@@ -61,6 +61,13 @@ Sorun zor olduğu için birçok çözüm mevcuttur; bazıları DX'e (geliştiric
 
 Intlayer tüm bu boyutlarda optimizasyon yapmaya çalışır.
 
+## TL;DR
+
+- **Intlayer** & **next-translate**: Next.js performansı için en iyi seçimler; en küçük ayak izini ve en iyi statik render desteğini sunarlar.
+- **next-intl**: Şu anki en popüler seçenek ancak ağır ve büyük uygulamalar için optimize edilmesi karmaşık.
+- **next-i18next**: Popüler ve eklenti bakımından zengin ancak önemli bir paket ağırlığı getiriyor (~3× Intlayer).
+- **Kaçının**: Ciddi performans sorunları, satıcı kısıtlaması (vendor lock-in) ve derlemeyi bozan hatalar nedeniyle **gt-next** ve **lingo.dev**'den kaçının.
+
 ## Uygulamanızı Test Edin
 
 Bu sorunları ortaya çıkarmak için [buradan](https://intlayer.org/i18n-seo-scanner) deneyebileceğiniz ücretsiz bir tarayıcı oluşturdum.
@@ -99,14 +106,14 @@ Son olarak `Intlayer`, derleme zamanı (build-time) optimizasyonu uygulayarak `u
 Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
 
 - `Base App` (i18n kütüphanesi yok)
-- `next-intlayer` (v8.7.5)
+- `next-intlayer` (v8.7.12)
 - `next-i18next` (v16.0.5)
 - `next-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `next-translate` (v3.1.2)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `@lingo.dev/compiler` (v0.4.0)
 - `wuchale` (v0.22.11)
 - `gt-next` (v6.16.5)
@@ -161,10 +168,10 @@ Karşılaşılan sorunlar:
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- 110kb'lık bir uygulama için `gt-react` 440kb'tan fazla ek veri ekler.
+- 110kb'lık bir uygulama için `gt-next` 440kb'tan fazla ek veri ekler.
 - General Translation ile yapılan ilk derlemede `Quota Exceeded, please upgrade your plan` mesajı.
 - Çeviriler render edilmiyor; kütüphanede bir hata gibi görünen `Error: <T> used on the client-side outside of <GTProvider>` hatası alıyorum.
-- **gt-tanstack-start-react** uygulanırken kütüphaneyle ilgili bir [sorun](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) ile de karşılaştım: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser` hatası uygulamayı bozdu. Sorun bildirildikten sonra 24 saat içinde düzeltildi.
+- **gt-next** uygulanırken kütüphaneyle ilgili bir [sorun](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) ile de karşılaştım: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser` hatası uygulamayı bozdu. Sorun bildirildikten sonra 24 saat içinde düzeltildi.
 - Kütüphane Next.js sayfalarının statik render edilmesini engelliyor.
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
@@ -186,9 +193,11 @@ Karşılaşılan sorunlar:
 Şahsen her push öncesinde JS dosyalarını yeniden oluşturmak zorunda kalmaktan hoşlanmıyorum, bu da PR'ler üzerinden sürekli merge çelişkisi riski yaratıyor. Araç ayrıca Next.js'ten ziyade Vite'e daha fazla odaklanmış gibi görünüyor.
 Son olarak, diğer çözümlerle karşılaştırıldığında Paraglide, içeriği render etmek için mevcut dili almak üzere bir store (örneğin React context) kullanmaz. Ayrıştırılan her düğüm için localStorage / cookie vb. üzerinden dili sorgular. Bu, bileşen reaktivitesini etkileyen gereksiz mantık yürütülmesine yol açar.
 
+> Paraglide üzerine not: Bu çözüm, içe aktarma (import) için kod tabanınıza kod enjekte eder ve sonuç olarak benchmark raporundaki 'kütüphane boyutu' metriği neredeyse 0'dır. Kod oluşturma iyi bir şeydir, çünkü kullanılan fonksiyon yalnızca gerekli mantığı (tüm önekler vs önek yok, çerezler vs depolama vb.) içerecektir. Buna karşılık Intlayer, paketleyiciyi mantığa bağlı olarak içeriği tree-shake yapmaya zorlamak için derlemede ortam değişkeni enjeksiyonları yoluyla bu filtrelemeyi gerçekleştirir. Bu sayede paraglide ve intlayer, i18next veya next-intl'den 6 ila 10 kat daha hafif çözümler haline gelir.
+
 ### 3 — Kabul edilebilir çözümler
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` daha önce bahsedilen sorunların çoğunu ele alıyor. Benzer araçlara göre benimsenmesinin daha zor olduğunu gördüm. Tip güvenliği (type safety) sağlamıyor, bu da eksik anahtarların derleme zamanında yakalanmasını zorlaştırıyor. Eksik anahtar algılama özelliği eklemek için Tolgee'nin fonksiyonlarını kendi fonksiyonlarımla sarmak zorunda kaldım.
 
@@ -216,7 +225,7 @@ Mesaj formatları da farklıdır: `next-intl` ICU MessageFormat kullanırken, `i
 
 `t()` stili bir API seviyorsanız `next-translate` ana önerimdir. `next-translate-plugin` aracılığıyla zarif bir şekilde çalışır ve Webpack / Turbopack yükleyicisi ile `getStaticProps` üzerinden ad alanlarını yükler. Ayrıca buradaki en hafif seçenektir (~2.5kb). Yapılandırmada sayfa veya rota başına ad alanı tanımlamak iyi düşünülmüştür ve **next-intl** veya **next-i18next** gibi ana alternatiflerden daha kolay bakımı yapılır. `3.1.2` sürümünde statik render'ın çalışmadığını ve Next.js'in dinamik render'a geri döndüğünü fark ettim.
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 Nesnellik adına kendi çözümüm olan `next-intlayer` hakkında kişisel olarak yorum yapmayacağım.
 

package/docs/tr/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026'da Solid için En İyi i18n Çözümü - Benchmark Raporu
+description: solid-primitives, solid-i18next ve Intlayer gibi Solid uluslararasılaştırma (i18n) kütüphanelerini karşılaştırın. Paket boyutu, sızıntı ve reaktivite üzerine ayrıntılı performans raporu.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - performans
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Benchmark başlatıldı"
+---
+
+# Solid i18n Kütüphaneleri — 2026 Benchmark Raporu
+
+Bu sayfa, Solid üzerindeki i18n çözümleri için bir benchmark raporudur.
+
+## İçindekiler
+
+<Toc/>
+
+## İnteraktif Benchmark
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Sonuç referansı:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+Tüm benchmark deposunu [burada](https://github.com/intlayer-org/benchmark-i18n/tree/main) görebilirsiniz.
+
+## Giriş
+
+Uluslararasılaştırma çözümleri, bir Solid uygulamasındaki en ağır bağımlılıklar arasındadır. Ana risk, gereksiz içerik göndermektir: tek bir rota paketinde diğer sayfalar ve diğer diller için çeviriler.
+
+Uygulamanız büyüdükçe, bu sorun istemciye gönderilen JavaScript'i hızla büyütebilir ve navigasyonu yavaşlatabilir.
+
+Pratikte, en az optimize edilmiş uygulamalar için, uluslararasılaştırılmış bir sayfa i18n olmayan sürümden birkaç kat daha ağır olabilir.
+
+Diğer etki geliştirici deneyimi (DX) üzerindedir: içeriği nasıl tanımladığınız, tipler, namespace organizasyonu, dinamik yükleme ve dil değiştiğinde reaktivite.
+
+## TL;DR
+
+- **Intlayer**: Gelişmiş özelliklere ve optimizasyona ihtiyaç duyan profesyonel Solid uygulamaları için önerilen seçim (v8.7.12).
+- **@solid-primitives/i18n**: Basit projeler için mükemmel hafif bir alternatif, ancak lazy loading gibi gelişmiş özelliklerden yoksundur.
+- **solid-i18next**: Standart ancak ağır bir seçenek (~4.7x Intlayer), React i18next ile aynı dezavantajlara sahiptir.
+- **Paraglide**: Yenilikçi yaklaşım ancak karmaşık DX ve bazı kurulumlarda tree-shaking sorunları.
+
+## Uygulamanızı test edin
+
+i18n sızıntı sorunlarını hızlıca tespit etmek için [burada](https://intlayer.org/i18n-seo-scanner) mevcut olan ücretsiz bir tarayıcı kurdum.
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Sorun
+
+Çok dilli bir uygulamanın maliyetini sınırlamak için iki kaldıraç esastır:
+
+- İçeriği sayfa / namespace bazında bölün, böylece ihtiyacınız olmadığında tüm sözlükleri yüklemezsiniz.
+- Doğru dili dinamik olarak, yalnızca gerektiğinde yükleyin.
+
+Bu yaklaşımların teknik sınırlarını anlamak:
+
+**Dinamik yükleme**
+
+Dinamik yükleme olmadan, çoğu çözüm mesajları ilk render'dan itibaren bellekte tutar ve bu da birçok rota ve dile sahip uygulamalar için önemli bir yük ekler.
+
+Dinamik yükleme ile bir ödünleşimi kabul edersiniz: daha az başlangıç JS'i, ancak bazen dil değiştirirken ek bir istek.
+
+**İçerik bölme (Splitting)**
+
+`t('a.b.c')` etrafında inşa edilen söz dizimleri çok kullanışlıdır ancak genellikle çalışma zamanında büyük JSON nesnelerini tutmayı teşvik eder. Bu model, kütüphane sayfa başına gerçek bir bölme stratejisi sunmadıkça tree-shaking'i zorlaştırır.
+
+## Araştırma Metodolojisi
+
+Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
+
+- `Base App` (i18n kütüphanesi yok)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Framework, **10 sayfa** ve **10 dilden** oluşan çok dilli bir uygulamaya sahip `Solid`'dir.
+
+**Dört yükleme stratejisini** karşılaştırdık:
+
+| Strateji            | Namespace yok (global)                         | Namespace var (kapsamlı/scoped)                                          |
+| :------------------ | :--------------------------------------------- | :----------------------------------------------------------------------- |
+| **Statik yükleme**  | **Static**: Başlangıçta her şey bellekte.      | **Scoped static**: Namespace'e göre bölünmüş; başlangıçta her şey yüklü. |
+| **Dinamik yükleme** | **Dynamic**: Dil başına istek üzerine yükleme. | **Scoped dynamic**: Namespace ve dil başına hassas yükleme.              |
+
+## Strateji özeti
+
+- **Static**: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük paket boyutu.
+- **Dynamic**: Başlangıç ağırlığını azaltır (lazy-loading). Birçok diliniz olduğunda idealdir.
+- **Scoped static**: Karmaşık ek ağ istekleri olmadan kodu düzenli tutar (mantıksal ayrım).
+- **Scoped dynamic**: _Kod bölme_ ve performans için en iyi yaklaşım. Yalnızca geçerli görünüm ve aktif dil için gerekenleri yükleyerek belleği minimize eder.
+
+## Detaylı sonuçlar
+
+### 1 — Kaçınılması gereken çözümler
+
+> Solid ekosisteminde kaçınılması gereken net bir çözüm yoktur.
+
+### 2 — Kabul edilebilir çözümler
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` muhtemelen en popüler seçenektir çünkü JavaScript uygulaması i18n ihtiyaçlarını karşılayan ilklerden biriydi. Ayrıca belirli sorunlar için geniş bir topluluk eklentisi setine sahiptir.
+
+Paket ağırdır (~14.6kb, bu da `solid-intlayer`'ın yaklaşık 4.7 katıdır).
+
+Yine de, `t('a.b.c')` üzerine kurulu yığınlarla aynı ana dezavantajları paylaşır: optimizasyonlar mümkündür ancak çok zaman alıcıdır ve büyük projeler kötü uygulamalar (namespace + dinamik yükleme + tipler) riskiyle karşı karşıyadır.
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive son derece hafif ve verimlidir. Bu çözümü hafif projeler için öneriyorum, ancak çerez yönetimi, proxy yönlendirme, formatlayıcılar vb. dahil profesyonel çözümler için özellikleri hızla yetersiz kalabilir.
+Ayrıca sayfa boyutu optimizasyonu için lazy loading ve kapsamlı namespace özellikleri de eksiktir.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` yenilikçi ve iyi düşünülmüş bir yaklaşım sunuyor. Buna rağmen, bu benchmark'ta şirketlerinin reklamını yaptığı tree-shaking benim uygulamam için çalışmadı. İş akışı ve DX de diğer seçeneklerden daha karmaşıktır.
+Kişisel olarak her push'tan önce JS dosyalarını yeniden oluşturmak zorunda kalmayı sevmiyorum, bu da PR'lar aracılığıyla sürekli bir birleştirme çakışması riski yaratıyor.
+Son olarak, diğer çözümlerle karşılaştırıldığında Paraglide, içeriği işlemek için geçerli dili almak için bir store (örneğin Solid signal) kullanmaz. Ayrıştırılan her düğüm için localStorage / cookie vb.'den dili isteyecektir. Bu, bileşen reaktivitesini etkileyen gereksiz mantık yürütülmesine yol açar.
+
+### 3 — Öneriler
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Kendi çözümüm olduğu için tarafsızlık adına `solid-intlayer`'ı kişisel olarak yargılamayacağım.
+
+### Kişisel not
+
+Bu not kişiseldir ve benchmark sonuçlarını etkilemez. Yine de, i18n dünyasında çevrilmiş içerik için genellikle `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` gibi bir desen etrafında fikir birliği görürsünüz.
+
+Solid uygulamalarında, bir fonksiyonu `JSX.Element` olarak enjekte etmek benim görüşüme göre bir anti-desendir. Ayrıca kaçınılabilir bir karmaşıklık ve JavaScript yürütme yükü ekler (zar zor fark edilse bile).

package/docs/tr/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026'da Svelte için En İyi i18n Çözümü - Benchmark Raporu
+description: svelte-i18n, Paraglide ve Intlayer gibi Svelte uluslararasılaştırma (i18n) kütüphanelerini karşılaştırın. Paket boyutu, sızıntı ve reaktivite üzerine ayrıntılı performans raporu.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - performans
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Benchmark başlatıldı"
+---
+
+# Svelte i18n Kütüphaneleri — 2026 Benchmark Raporu
+
+Bu sayfa, Svelte üzerindeki i18n çözümleri için bir benchmark raporudur.
+
+## İçindekiler
+
+<Toc/>
+
+## İnteraktif Benchmark
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## Sonuç referansı:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
+
+Tüm benchmark deposunu [burada](https://github.com/intlayer-org/benchmark-i18n/tree/main) görebilirsiniz.
+
+## Giriş
+
+Uluslararasılaştırma çözümleri, bir Svelte uygulamasındaki en ağır bağımlılıklar arasındadır. Ana risk, gereksiz içerik göndermektir: tek bir rota paketinde diğer sayfalar ve diğer diller için çeviriler.
+
+Uygulamanız büyüdükçe, bu sorun istemciye gönderilen JavaScript'i hızla büyütebilir ve navigasyonu yavaşlatabilir.
+
+Pratikte, en az optimize edilmiş uygulamalar için, uluslararasılaştırılmış bir sayfa i18n olmayan sürümden birkaç kat daha ağır olabilir.
+
+Diğer etki geliştirici deneyimi (DX) üzerindedir: içeriği nasıl tanımladığınız, tipler, namespace organizasyonu, dinamik yükleme ve dil değiştiğinde reaktivite.
+
+## TL;DR
+
+- **Intlayer**: En küçük ayak izine sahip en performans odaklı seçim (v8.7.12).
+- **Paraglide**: Tree-shaking için güçlü bir rakip ancak daha karmaşık bir geliştirici deneyimine ve reaktivite yüküne sahip.
+- **svelte-i18n**: Svelte için kapsamlı ve standart, ancak çok daha büyük paket ağırlığı taşıyor (~7x Intlayer).
+
+## Uygulamanızı test edin
+
+i18n sızıntı sorunlarını hızlıca tespit etmek için [burada](https://intlayer.org/i18n-seo-scanner) mevcut olan ücretsiz bir tarayıcı kurdum.
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Sorun
+
+Çok dilli bir uygulamanın maliyetini sınırlamak için iki kaldıraç esastır:
+
+- İçeriği sayfa / namespace bazında bölün, böylece ihtiyacınız olmadığında tüm sözlükleri yüklemezsiniz.
+- Doğru dili dinamik olarak, yalnızca gerektiğinde yükleyin.
+
+Bu yaklaşımların teknik sınırlarını anlamak:
+
+**Dinamik yükleme**
+
+Dinamik yükleme olmadan, çoğu çözüm mesajları ilk render'dan itibaren bellekte tutar ve bu da birçok rota ve dile sahip uygulamalar için önemli bir yük ekler.
+
+Dinamik yükleme ile bir ödünleşimi kabul edersiniz: daha az başlangıç JS'i, ancak bazen dil değiştirirken ek bir istek.
+
+**İçerik bölme (Splitting)**
+
+`t('a.b.c')` etrafında inşa edilen söz dizimleri çok kullanışlıdır ancak genellikle çalışma zamanında büyük JSON nesnelerini tutmayı teşvik eder. Bu model, kütüphane sayfa başına gerçek bir bölme stratejisi sunmadıkça tree-shaking'i zorlaştırır.
+
+## Araştırma Metodolojisi
+
+Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
+
+- `Base App` (i18n kütüphanesi yok)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Framework, **10 sayfa** ve **10 dilden** oluşan çok dilli bir uygulamaya sahip `Svelte`'dir.
+
+**Dört yükleme stratejisini** karşılaştırdık:
+
+| Strateji            | Namespace yok (global)                         | Namespace var (kapsamlı/scoped)                                          |
+| :------------------ | :--------------------------------------------- | :----------------------------------------------------------------------- |
+| **Statik yükleme**  | **Static**: Başlangıçta her şey bellekte.      | **Scoped static**: Namespace'e göre bölünmüş; başlangıçta her şey yüklü. |
+| **Dinamik yükleme** | **Dynamic**: Dil başına istek üzerine yükleme. | **Scoped dynamic**: Namespace ve dil başına hassas yükleme.              |
+
+## Strateji özeti
+
+- **Static**: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük paket boyutu.
+- **Dynamic**: Başlangıç ağırlığını azaltır (lazy-loading). Birçok diliniz olduğunda idealdir.
+- **Scoped static**: Karmaşık ek ağ istekleri olmadan kodu düzenli tutar (mantıksal ayrım).
+- **Scoped dynamic**: _Kod bölme_ ve performans için en iyi yaklaşım. Yalnızca geçerli görünüm ve aktif dil için gerekenleri yükleyerek belleği minimize eder.
+
+## Detaylı sonuçlar
+
+### 1 — Kaçınılması gereken çözümler
+
+> Svelte ekosisteminde kaçınılması gereken net bir çözüm yoktur.
+
+### 2 — Kabul edilebilir çözümler
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` yenilikçi ve iyi düşünülmüş bir yaklaşım sunuyor. Bir Vite + Svelte uygulaması bağlamında, şirketlerinin reklamını yaptığı tree-shaking beklendiği gibi çalıştı, bu harika.
+Ancak React + TanStack Start durumunda tree-shaking beklendiği gibi çalışmadı, Next.js için de aynı durum geçerli. Bununla birlikte, Paraglide'ın Svelte ve TanStack Start projesindeki kullanımı bir kez daha kontrol edilmeye değer olacaktır.
+İş akışı ve DX de diğer seçeneklerden daha karmaşıktır.
+Kişisel olarak her push'tan önce JS dosyalarını yeniden oluşturmak zorunda kalmanın hayranı değilim, bu da PR'lar aracılığıyla sürekli bir birleştirme çakışması riski yaratıyor. Araç ayrıca Next.js'ten ziyade Vite'e daha fazla odaklanmış görünüyor.
+Son olarak, diğer çözümlerle karşılaştırıldığında Paraglide, içeriği işlemek için geçerli dili almak için bir store (örneğin Svelte store) kullanmaz. Ayrıştırılan her düğüm için localStorage / cookie vb.'den dili isteyecektir. Bu, bileşen reaktivitesini etkileyen gereksiz mantık yürütülmesine yol açar.
+
+> Paraglide üzerine not: çözüm, importlar için kod tabanınıza kod enjekte eder; sonuç olarak, benchmark raporundaki 'lib size' metriği neredeyse 0'dır. Kod üretimi iyi bir şeydir, çünkü kullanılan fonksiyon yalnızca gerekli mantığı (her yerde ön ek vs ön ek yok, çerez vs depolama vb.) içerecektir. Karşılaştırma yapıldığında, Intlayer bu filtrelemeyi mantığa bağlı olarak içeriği tree-shaking yapmaya zorlamak için build sırasında ortam değişkeni enjeksiyonları yoluyla gerçekleştirir. Bu sayede paraglide ve intlayer i18next veya next-intl'den 6 ila 10 kat daha hafif çözümler haline gelir.
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+
+Bu çözüm, bir Svelte projesindeki tüm i18n ihtiyaçlarını karşılar. Ancak i18next veya diğer büyük i18n çözümlerinde olduğu gibi, biraz ağırdır (~15.9kb, bu da `svelte-intlayer`'ın yaklaşık 7 katıdır).
+
+### 3 — Öneriler
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+Kendi çözümüm olduğu için tarafsızlık adına `svelte-intlayer`'ı kişisel olarak yargılamayacağım.
+
+### Kişisel not
+
+Bu not kişiseldir ve benchmark sonuçlarını etkilemez. Yine de, i18n dünyasında çevrilmiş içerik için genellikle `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` gibi bir desen etrafında fikir birliği görürsünüz.
+
+Svelte uygulamalarında, bir fonksiyonu `Slot` olarak enjekte etmek benim görüşüme göre bir anti-desendir. Ayrıca kaçınılabilir bir karmaşıklık ve JavaScript yürütme yükü ekler (zar zor fark edilse bile).

package/docs/tr/benchmark/tanstack.md

@@ -57,6 +57,13 @@ Pratikte, en az optimize edilmiş uygulamalar için uluslararasılaştırılmı
 
 Diğer bir etki ise geliştirici deneyimidir (DX): içeriği nasıl tanımladığınız, tipler, ad alanı (namespace) organizasyonu, dinamik yükleme ve yerel ayar değiştiğinde verilen reaktif yanıt.
 
+## TL;DR
+
+- **Intlayer**: TanStack Start için en iyi performansı ve en küçük paket boyutunu (v8.7.12) sağlar.
+- **react-i18next** & **use-intl**: Geniş ekosistemlere sahip olgun alternatiflerdir, ancak optimize edilmeleri önemli ölçüde daha ağır ve karmaşıktır.
+- **Paraglide**: Kağıt üzerinde yenilikçi bir tree-shaking fikridir ancak pratikte çalışmaz. TanStack Start'ta karmaşık DX ve reaktivite ek yükü oluşturur.
+- **Kaçının**: Ciddi performans sorunları, AI kota sınırları ve satıcı kilidi (vendor lock-in) nedeniyle **General Translation (GT)** ve **Lingo.dev**.
+
 ## Uygulamanızı Test Edin
 
 i18n sızıntısı (leakage) sorunlarını hızlıca tespit etmek için [buradan](https://intlayer.org/i18n-seo-scanner) erişilebilen ücretsiz bir tarayıcı hazırladım.
@@ -87,12 +94,12 @@ Dinamik yükleme ile bir ödün vermeyi kabul edersiniz: daha az başlangıç JS
 Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
 
 - `Base App` (i18n kütüphanesi yok)
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ Karşılaşılan sorunlar:
 
 `Paraglide` yenilikçi ve iyi düşünülmüş bir yaklaşım sunuyor. Buna rağmen, bu benchmark'ta şirketlerinin reklamını yaptığı tree-shaking benim Next.js uygulamamda veya TanStack Start için çalışmadı. İş akışı ve DX de diğer seçeneklerden daha karmaşık. Şahsen her push öncesinde JS dosyalarını yeniden oluşturmak zorunda kalmaktan hoşlanmıyorum, bu da PR'ler üzerinden geliştiriciler için sürekli merge çelişkisi riski yaratıyor.
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> paraglide üzerine not: Bu çözüm, içe aktarmalar (imports) için kod tabanınıza kod enjekte eder; sonuç olarak, benchmark raporundaki 'lib size' metriği neredeyse 0'dır. Kod üretimi (Code generation) iyi bir şeydir, porque kullanılan fonksiyon yalnızca gerekli mantığı (her yerde ön ek vs. ön ek yok, çerez vs. depolama vb.) içerecektir. Buna karşılık Intlayer, mantığa bağlı olarak paketleyicinin (bundler) içeriği tree-shake etmesini sağlamak için derleme sırasında ortam değişkeni enjeksiyonları yoluyla bu filtrelemeyi gerçekleştirir. Bu sayede paraglide ve intlayer, i18next veya next-intl'den 6 ila 10 kat daha hafif çözümler haline gelir.
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` daha önce bahsedilen sorunların çoğunu ele alıyor. Benzer yaklaşımlara sahip diğer araçlara göre başlamasının daha zor olduğunu gördüm. Tip güvenliği sağlamıyor, bu da eksik anahtarların derleme zamanında yakalanmasını çok zorlaştırıyor. Eksik anahtar algılama özelliği eklemek için Tolgee'nin API'larını kendi API'larımla sarmak zorunda kaldım.
 

package/docs/tr/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026'da Vue için En İyi i18n Çözümü - Benchmark Raporu
+description: vue-i18n, fluent-vue ve Intlayer gibi Vue uluslararasılaştırma (i18n) kütüphanelerini karşılaştırın. Paket boyutu, sızıntı ve reaktivite üzerine ayrıntılı performans raporu.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - performans
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Benchmark başlatıldı"
+---
+
+# Vue i18n Kütüphaneleri — 2026 Benchmark Raporu
+
+Bu sayfa, Vue üzerindeki i18n çözümleri için bir benchmark raporudur.
+
+## İçindekiler
+
+<Toc/>
+
+## İnteraktif Benchmark
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## Sonuç referansı:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
+
+Tüm benchmark deposunu [burada](https://github.com/intlayer-org/benchmark-i18n/tree/main) görebilirsiniz.
+
+## Giriş
+
+Uluslararasılaştırma çözümleri, bir Vue uygulamasındaki en ağır bağımlılıklar arasındadır. Ana risk, gereksiz içerik göndermektir: tek bir rota paketinde diğer sayfalar ve diğer diller için çeviriler.
+
+Uygulamanız büyüdükçe, bu sorun istemciye gönderilen JavaScript'i hızla büyütebilir ve navigasyonu yavaşlatabilir.
+
+Pratikte, en az optimize edilmiş uygulamalar için, uluslararasılaştırılmış bir sayfa i18n olmayan sürümden birkaç kat daha ağır olabilir.
+
+Diğer etki geliştirici deneyimi (DX) üzerindedir: içeriği nasıl tanımladığınız, tipler, namespace organizasyonu, dinamik yükleme ve dil değiştiğinde reaktivite.
+
+## TL;DR
+
+- **Intlayer**: Yerel kapsam (scoping) ve dinamik yükleme ile en hafif çözüm (v8.7.12).
+- **vue-i18n**: Zengin bir ekosisteme sahip endüstri standardı, ancak büyük uygulamalarda önemli ölçüde ağırlaşabilir ve kod bölme (code-splitting) için optimize edilmesi zor olabilir.
+- **fluent-vue**: Yenilikçi mesaj organizasyonu ancak tip güvenliğinden yoksundur ve son derece ağır bir çözüm olduğu ortaya çıkmıştır.
+
+## Uygulamanızı test edin
+
+i18n sızıntı sorunlarını hızlıca tespit etmek için [burada](https://intlayer.org/i18n-seo-scanner) mevcut olan ücretsiz bir tarayıcı kurdum.
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Sorun
+
+Çok dilli bir uygulamanın maliyetini sınırlamak için iki kaldıraç esastır:
+
+- İçeriği sayfa / namespace bazında bölün, böylece ihtiyacınız olmadığında tüm sözlükleri yüklemezsiniz.
+- Doğru dili dinamik olarak, yalnızca gerektiğinde yükleyin.
+
+Bu yaklaşımların teknik sınırlarını anlamak:
+
+**Dinamik yükleme**
+
+Dinamik yükleme olmadan, çoğu çözüm mesajları ilk render'dan itibaren bellekte tutar ve bu da birçok rota ve dile sahip uygulamalar için önemli bir yük ekler.
+
+Dinamik yükleme ile bir ödünleşimi kabul edersiniz: daha az başlangıç JS'i, ancak bazen dil değiştirirken ek bir istek.
+
+**İçerik bölme (Splitting)**
+
+`const { t } = useI18n()` + `t('a.b.c')` etrafında inşa edilen söz dizimleri çok kullanışlıdır ancak genellikle çalışma zamanında büyük JSON nesnelerini tutmayı teşvik eder. Bu model, kütüphane sayfa başına gerçek bir bölme stratejisi sunmadıkça tree-shaking'i zorlaştırır.
+
+## Araştırma Metodolojisi
+
+Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
+
+- `Base App` (i18n kütüphanesi yok)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+Framework, **10 sayfa** ve **10 dilden** oluşan çok dilli bir uygulamaya sahip `Vue`'dur.
+
+**Dört yükleme stratejisini** karşılaştırdık:
+
+| Strateji            | Namespace yok (global)                         | Namespace var (kapsamlı/scoped)                                          |
+| :------------------ | :--------------------------------------------- | :----------------------------------------------------------------------- |
+| **Statik yükleme**  | **Static**: Başlangıçta her şey bellekte.      | **Scoped static**: Namespace'e göre bölünmüş; başlangıçta her şey yüklü. |
+| **Dinamik yükleme** | **Dynamic**: Dil başına istek üzerine yükleme. | **Scoped dynamic**: Namespace ve dil başına hassas yükleme.              |
+
+## Strateji özeti
+
+- **Static**: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük paket boyutu.
+- **Dynamic**: Başlangıç ağırlığını azaltır (lazy-loading). Birçok diliniz olduğunda idealdir.
+- **Scoped static**: Karmaşık ek ağ istekleri olmadan kodu düzenli tutar (mantıksal ayrım).
+- **Scoped dynamic**: _Kod bölme_ ve performans için en iyi yaklaşım. Yalnızca geçerli görünüm ve aktif dil için gerekenleri yükleyerek belleği minimize eder.
+
+### Neyi ölçtüm:
+
+Her yığın için gerçek bir tarayıcıda aynı çok dilli uygulamayı çalıştırdım, ardından ağda gerçekte neyin göründüğünü ve işlerin ne kadar sürdüğünü not ettim. Boyutlar, insanların gerçekte ne indirdiğine ham kaynak sayımlarından daha yakın olduğu için **normal web sıkıştırmasından sonra** rapor edilir.
+
+- **Uluslararasılaştırma kütüphanesi boyutu**: Paketleme, tree-shaking ve minifikasyondan sonra, i18n kütüphanesinin boyutu boş bir bileşendeki provider'lar + composable'lar kodunun boyutudur. Çeviri dosyalarının yüklenmesini içermez. İçeriğiniz devreye girmeden önce kütüphanenin ne kadar "pahalı" olduğunu yanıtlar.
+
+- **Sayfa başına JavaScript**: Her benchmark rotası için, tarayıcının o ziyaret için çektiği script miktarı, paketteki sayfalar (ve diller) genelinde ortalaması alınmıştır. Ağır sayfalar yavaş sayfalardır.
+
+- **Diğer dillerden sızıntı (Leakage)**: Aynı sayfanın ancak denetlenen sayfada yanlışlıkla yüklenecek olan başka bir dildeki içeriğidir. Bu içerik gereksizdir ve kaçınılmalıdır (örneğin: `/en/about` sayfa paketindeki `/fr/about` sayfa içeriği).
+
+- **Diğer rotalardan sızıntı**: Uygulamadaki **diğer ekranlar** için de aynı fikir: yalnızca bir sayfa açtığınızda metinlerinin gelip gelmediği (örneğin: `/en/contact` sayfa paketindeki `/en/about` sayfa içeriği). Yüksek puan, zayıf bölme veya aşırı geniş paketlere işaret eder.
+
+- **Ortalama bileşen paket boyutu**: Yaygın UI parçaları, devasa bir uygulama sayısının içinde saklanmak yerine **tek tek** ölçülür. Uluslararasılaştırmanın günlük bileşenleri sessizce şişirip şişirmediğini gösterir. Örneğin, bileşeniniz yeniden render edilirse, tüm bu verileri bellekten yükleyecektir. Herhangi bir bileşene devasa bir JSON eklemek, bileşenlerinizin performansını yavaşlatacak büyük bir kullanılmayan veri deposu bağlamak gibidir.
+
+- **Dil değiştirme hızı**: Uygulamanın kendi kontrolünü kullanarak dili değiştiriyorum ve sayfanın net bir şekilde değiştiği ana kadar geçen süreyi ölçüyorum (bir ziyaretçinin fark edeceği şey).
+
+- **Dil değişikliğinden sonra render işi**: Daha hassas bir takip: geçiş başladıktan sonra arayüzün yeni dil için yeniden çizilmek için ne kadar çaba sarf ettiği. "Hissedilen" süre ve framework maliyeti farklılaştığında kullanışlıdır.
+
+- **İlk sayfa yükleme süresi**: Navigasyondan tarayıcının test ettiğim senaryolar için sayfayı tamamen yüklendi kabul ettiği ana kadar. Soğuk başlangıçları karşılaştırmak için iyidir.
+
+- **Hidrasyon süresi (Hydration)**: İstemcinin sunucu HTML'ini etkileşimli bir arayüze dönüştürmek için harcadığı süre. Tablolardaki tire, bu uygulamanın bu benchmark'ta güvenilir bir hidrasyon figürü sağlamadığı anlamına gelir.
+
+## Detaylı sonuçlar
+
+### 1 — Kaçınılması gereken çözümler
+
+> Vue ekosisteminde kaçınılması gereken net bir çözüm yoktur.
+
+### 2 — Kabul edilebilir çözümler
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **vue-i18n** tartışmasız Vue için en çok kullanılan i18n kütüphanesidir, birçok özelliği ve devasa bir ekosistemi vardır. Ancak kaputun altında çözüm oldukça ağırdır. vue-i18n mesajlar için lazy loading entegre etse bile, kapsam (scoping) özelliği eksiktir. Klasik bir Vue SPA uygulaması durumunda sorun yoktur, ancak @nuxt/i18n kullanan bir nuxt uygulaması için, tüm sayfalardan gelen mesajların tek bir sayfaya dahil edilmesine yol açar. 10'dan fazla sayfa içeren büyük bir nuxt uygulaması için bu gerçekten sorunlu olabilir.
+
+Paket çok ağırdır (~24.3kb, bu da `vue-intlayer`'ın yaklaşık 9 katıdır).
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **fluent-vue** .ftl formatı aracılığıyla yenilikçi bir girişim sunar. Mesaj organizasyonu harikadır, başlaması daha kolaydır. Ancak pratikte tip güvenliği eksikliği hata riskini artırır ve hata ayıklaması hızla zaman alıcı hale gelebilir. Dahası, bu çözüm mesajları her sayfada her dildeki tüm içeriğin yüklenmesini zorlayan bir vite eklentisi kullanarak yükler. Ek olarak, bu son derece ağır bir çözümdür (~92.7kb, bu da `vue-intlayer`'ın yaklaşık 34 katıdır).
+
+### 3 — Öneriler
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+Kendi çözümüm olduğu için tarafsızlık adına `vue-intlayer`'ı kişisel olarak yargılamayacağım.