@intlayer/docs 8.9.4-canary.0 → 8.9.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cjs/generated/docs.entry.cjs +20 -0
- package/dist/cjs/generated/docs.entry.cjs.map +1 -1
- package/dist/esm/generated/docs.entry.mjs +20 -0
- package/dist/esm/generated/docs.entry.mjs.map +1 -1
- package/dist/types/generated/docs.entry.d.ts +1 -0
- package/dist/types/generated/docs.entry.d.ts.map +1 -1
- package/docs/ar/benchmark/index.md +0 -3
- package/docs/ar/benchmark/nextjs.md +15 -6
- package/docs/ar/benchmark/solid.md +155 -0
- package/docs/ar/benchmark/svelte.md +148 -0
- package/docs/ar/benchmark/tanstack.md +12 -3
- package/docs/ar/benchmark/vue.md +160 -0
- package/docs/ar/configuration.md +16 -12
- package/docs/ar/dictionary/content_file.md +51 -1
- package/docs/ar/mcp_server.md +30 -17
- package/docs/ar/plugins/sync-po.md +333 -0
- package/docs/bn/configuration.md +16 -12
- package/docs/cs/configuration.md +16 -12
- package/docs/de/benchmark/index.md +0 -3
- package/docs/de/benchmark/nextjs.md +15 -6
- package/docs/de/benchmark/solid.md +155 -0
- package/docs/de/benchmark/svelte.md +148 -0
- package/docs/de/benchmark/tanstack.md +12 -3
- package/docs/de/benchmark/vue.md +160 -0
- package/docs/de/configuration.md +16 -12
- package/docs/de/dictionary/content_file.md +52 -2
- package/docs/de/mcp_server.md +29 -16
- package/docs/de/plugins/sync-po.md +332 -0
- package/docs/en/benchmark/nextjs.md +11 -2
- package/docs/en/benchmark/solid.md +22 -4
- package/docs/en/benchmark/svelte.md +17 -5
- package/docs/en/benchmark/tanstack.md +18 -3
- package/docs/en/benchmark/vue.md +17 -11
- package/docs/en/configuration.md +16 -13
- package/docs/en/dictionary/content_file.md +51 -1
- package/docs/en/mcp_server.md +31 -18
- package/docs/en/plugins/sync-po.md +333 -0
- package/docs/en-GB/benchmark/index.md +0 -3
- package/docs/en-GB/benchmark/nextjs.md +15 -6
- package/docs/en-GB/benchmark/solid.md +155 -0
- package/docs/en-GB/benchmark/svelte.md +148 -0
- package/docs/en-GB/benchmark/tanstack.md +12 -3
- package/docs/en-GB/benchmark/vue.md +160 -0
- package/docs/en-GB/configuration.md +15 -11
- package/docs/en-GB/dictionary/content_file.md +51 -1
- package/docs/en-GB/mcp_server.md +31 -18
- package/docs/en-GB/plugins/sync-po.md +333 -0
- package/docs/es/benchmark/index.md +0 -3
- package/docs/es/benchmark/nextjs.md +15 -6
- package/docs/es/benchmark/solid.md +155 -0
- package/docs/es/benchmark/svelte.md +148 -0
- package/docs/es/benchmark/tanstack.md +12 -3
- package/docs/es/benchmark/vue.md +160 -0
- package/docs/es/configuration.md +16 -12
- package/docs/es/dictionary/content_file.md +51 -1
- package/docs/es/mcp_server.md +30 -17
- package/docs/es/plugins/sync-po.md +333 -0
- package/docs/fr/benchmark/index.md +0 -3
- package/docs/fr/benchmark/nextjs.md +15 -6
- package/docs/fr/benchmark/solid.md +155 -0
- package/docs/fr/benchmark/svelte.md +148 -0
- package/docs/fr/benchmark/tanstack.md +12 -3
- package/docs/fr/benchmark/vue.md +160 -0
- package/docs/fr/configuration.md +16 -12
- package/docs/fr/dictionary/content_file.md +51 -1
- package/docs/fr/mcp_server.md +30 -17
- package/docs/fr/plugins/sync-po.md +333 -0
- package/docs/hi/benchmark/nextjs.md +15 -6
- package/docs/hi/benchmark/solid.md +155 -0
- package/docs/hi/benchmark/svelte.md +148 -0
- package/docs/hi/benchmark/tanstack.md +12 -3
- package/docs/hi/benchmark/vue.md +160 -0
- package/docs/hi/configuration.md +16 -12
- package/docs/hi/dictionary/content_file.md +51 -1
- package/docs/hi/mcp_server.md +31 -18
- package/docs/hi/plugins/sync-po.md +333 -0
- package/docs/id/benchmark/index.md +0 -3
- package/docs/id/benchmark/nextjs.md +15 -6
- package/docs/id/benchmark/solid.md +155 -0
- package/docs/id/benchmark/svelte.md +148 -0
- package/docs/id/benchmark/tanstack.md +12 -3
- package/docs/id/benchmark/vue.md +160 -0
- package/docs/id/configuration.md +16 -12
- package/docs/id/dictionary/content_file.md +51 -1
- package/docs/id/mcp_server.md +30 -17
- package/docs/id/plugins/sync-po.md +333 -0
- package/docs/it/benchmark/index.md +1 -4
- package/docs/it/benchmark/nextjs.md +15 -6
- package/docs/it/benchmark/solid.md +155 -0
- package/docs/it/benchmark/svelte.md +148 -0
- package/docs/it/benchmark/tanstack.md +12 -3
- package/docs/it/benchmark/vue.md +160 -0
- package/docs/it/configuration.md +16 -12
- package/docs/it/dictionary/content_file.md +51 -1
- package/docs/it/mcp_server.md +30 -17
- package/docs/it/plugins/sync-po.md +333 -0
- package/docs/ja/benchmark/index.md +5 -5
- package/docs/ja/benchmark/nextjs.md +15 -6
- package/docs/ja/benchmark/solid.md +155 -0
- package/docs/ja/benchmark/svelte.md +148 -0
- package/docs/ja/benchmark/tanstack.md +12 -3
- package/docs/ja/benchmark/vue.md +160 -0
- package/docs/ja/configuration.md +16 -12
- package/docs/ja/dictionary/content_file.md +50 -2
- package/docs/ja/intlayer_with_nextjs_no_locale_path.md +4 -3
- package/docs/ja/mcp_server.md +29 -16
- package/docs/ja/plugins/sync-po.md +333 -0
- package/docs/ko/benchmark/nextjs.md +15 -6
- package/docs/ko/benchmark/solid.md +155 -0
- package/docs/ko/benchmark/svelte.md +148 -0
- package/docs/ko/benchmark/tanstack.md +12 -3
- package/docs/ko/benchmark/vue.md +160 -0
- package/docs/ko/configuration.md +16 -12
- package/docs/ko/dictionary/content_file.md +51 -1
- package/docs/ko/intlayer_with_nextjs_no_locale_path.md +3 -2
- package/docs/ko/mcp_server.md +31 -18
- package/docs/ko/plugins/sync-po.md +333 -0
- package/docs/nl/configuration.md +16 -12
- package/docs/pl/benchmark/index.md +0 -3
- package/docs/pl/benchmark/nextjs.md +15 -6
- package/docs/pl/benchmark/solid.md +155 -0
- package/docs/pl/benchmark/svelte.md +148 -0
- package/docs/pl/benchmark/tanstack.md +12 -3
- package/docs/pl/benchmark/vue.md +160 -0
- package/docs/pl/configuration.md +16 -12
- package/docs/pl/dictionary/content_file.md +51 -1
- package/docs/pl/mcp_server.md +30 -17
- package/docs/pl/plugins/sync-po.md +333 -0
- package/docs/pt/benchmark/index.md +0 -3
- package/docs/pt/benchmark/nextjs.md +16 -7
- package/docs/pt/benchmark/solid.md +155 -0
- package/docs/pt/benchmark/svelte.md +148 -0
- package/docs/pt/benchmark/tanstack.md +13 -4
- package/docs/pt/benchmark/vue.md +160 -0
- package/docs/pt/configuration.md +16 -12
- package/docs/pt/dictionary/content_file.md +51 -1
- package/docs/pt/mcp_server.md +30 -17
- package/docs/pt/plugins/sync-po.md +333 -0
- package/docs/ru/benchmark/nextjs.md +15 -6
- package/docs/ru/benchmark/solid.md +155 -0
- package/docs/ru/benchmark/svelte.md +148 -0
- package/docs/ru/benchmark/tanstack.md +12 -3
- package/docs/ru/benchmark/vue.md +160 -0
- package/docs/ru/configuration.md +16 -12
- package/docs/ru/dictionary/content_file.md +52 -2
- package/docs/ru/mcp_server.md +30 -17
- package/docs/ru/plugins/sync-po.md +333 -0
- package/docs/tr/benchmark/index.md +0 -3
- package/docs/tr/benchmark/nextjs.md +15 -6
- package/docs/tr/benchmark/solid.md +155 -0
- package/docs/tr/benchmark/svelte.md +148 -0
- package/docs/tr/benchmark/tanstack.md +12 -3
- package/docs/tr/benchmark/vue.md +160 -0
- package/docs/tr/configuration.md +16 -12
- package/docs/tr/dictionary/content_file.md +51 -1
- package/docs/tr/mcp_server.md +31 -18
- package/docs/tr/plugins/sync-po.md +333 -0
- package/docs/uk/benchmark/nextjs.md +15 -6
- package/docs/uk/benchmark/solid.md +155 -0
- package/docs/uk/benchmark/svelte.md +148 -0
- package/docs/uk/benchmark/tanstack.md +12 -3
- package/docs/uk/benchmark/vue.md +160 -0
- package/docs/uk/configuration.md +16 -12
- package/docs/uk/dictionary/content_file.md +51 -1
- package/docs/uk/mcp_server.md +29 -16
- package/docs/uk/plugins/sync-po.md +333 -0
- package/docs/ur/configuration.md +16 -12
- package/docs/vi/benchmark/index.md +0 -3
- package/docs/vi/benchmark/nextjs.md +15 -6
- package/docs/vi/benchmark/solid.md +155 -0
- package/docs/vi/benchmark/svelte.md +148 -0
- package/docs/vi/benchmark/tanstack.md +12 -3
- package/docs/vi/benchmark/vue.md +160 -0
- package/docs/vi/configuration.md +16 -12
- package/docs/vi/dictionary/content_file.md +51 -1
- package/docs/vi/intlayer_with_nextjs_15.md +10 -57
- package/docs/vi/mcp_server.md +30 -17
- package/docs/vi/plugins/sync-po.md +333 -0
- package/docs/zh/benchmark/nextjs.md +15 -6
- package/docs/zh/benchmark/solid.md +155 -0
- package/docs/zh/benchmark/svelte.md +148 -0
- package/docs/zh/benchmark/tanstack.md +12 -3
- package/docs/zh/benchmark/vue.md +160 -0
- package/docs/zh/configuration.md +16 -12
- package/docs/zh/dictionary/content_file.md +51 -3
- package/docs/zh/mcp_server.md +31 -18
- package/docs/zh/plugins/sync-po.md +333 -0
- package/frequent_questions/ar/intlayerNode.md +3 -3
- package/frequent_questions/de/intlayerNode.md +3 -3
- package/frequent_questions/en/intlayerNode.md +3 -3
- package/frequent_questions/en-GB/intlayerNode.md +3 -3
- package/frequent_questions/es/intlayerNode.md +3 -3
- package/frequent_questions/fr/intlayerNode.md +3 -3
- package/frequent_questions/hi/intlayerNode.md +3 -3
- package/frequent_questions/id/intlayerNode.md +3 -3
- package/frequent_questions/it/intlayerNode.md +3 -3
- package/frequent_questions/ja/intlayerNode.md +3 -3
- package/frequent_questions/ko/intlayerNode.md +3 -3
- package/frequent_questions/pl/intlayerNode.md +3 -3
- package/frequent_questions/pt/intlayerNode.md +3 -3
- package/frequent_questions/ru/intlayerNode.md +3 -3
- package/frequent_questions/tr/intlayerNode.md +3 -3
- package/frequent_questions/uk/intlayerNode.md +3 -3
- package/frequent_questions/vi/intlayerNode.md +3 -3
- package/frequent_questions/zh/intlayerNode.md +3 -3
- package/package.json +8 -8
- package/src/generated/docs.entry.ts +20 -0
|
@@ -0,0 +1,155 @@
|
|
|
1
|
+
---
|
|
2
|
+
createdAt: 2026-04-20
|
|
3
|
+
updatedAt: 2026-04-21
|
|
4
|
+
title: 2026'da Solid için En İyi i18n Çözümü - Benchmark Raporu
|
|
5
|
+
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.
|
|
6
|
+
keywords:
|
|
7
|
+
- benchmark
|
|
8
|
+
- i18n
|
|
9
|
+
- intl
|
|
10
|
+
- solid
|
|
11
|
+
- performans
|
|
12
|
+
- intlayer
|
|
13
|
+
slugs:
|
|
14
|
+
- doc
|
|
15
|
+
- benchmark
|
|
16
|
+
- solid
|
|
17
|
+
author: Aymeric PINEAU
|
|
18
|
+
applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
|
|
19
|
+
history:
|
|
20
|
+
- version: 8.7.12
|
|
21
|
+
date: 2026-01-06
|
|
22
|
+
changes: "Benchmark başlatıldı"
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
# Solid i18n Kütüphaneleri — 2026 Benchmark Raporu
|
|
26
|
+
|
|
27
|
+
Bu sayfa, Solid üzerindeki i18n çözümleri için bir benchmark raporudur.
|
|
28
|
+
|
|
29
|
+
## İçindekiler
|
|
30
|
+
|
|
31
|
+
<Toc/>
|
|
32
|
+
|
|
33
|
+
## İnteraktif Benchmark
|
|
34
|
+
|
|
35
|
+
<I18nBenchmark framework="vite-solid" vertical/>
|
|
36
|
+
|
|
37
|
+
## Sonuç referansı:
|
|
38
|
+
|
|
39
|
+
<iframe
|
|
40
|
+
src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md"
|
|
41
|
+
width="100%"
|
|
42
|
+
height="600px"
|
|
43
|
+
style="border:none;">
|
|
44
|
+
</iframe>
|
|
45
|
+
|
|
46
|
+
> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
|
|
47
|
+
|
|
48
|
+
Tüm benchmark deposunu [burada](https://github.com/intlayer-org/benchmark-i18n/tree/main) görebilirsiniz.
|
|
49
|
+
|
|
50
|
+
## Giriş
|
|
51
|
+
|
|
52
|
+
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.
|
|
53
|
+
|
|
54
|
+
Uygulamanız büyüdükçe, bu sorun istemciye gönderilen JavaScript'i hızla büyütebilir ve navigasyonu yavaşlatabilir.
|
|
55
|
+
|
|
56
|
+
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.
|
|
57
|
+
|
|
58
|
+
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.
|
|
59
|
+
|
|
60
|
+
## TL;DR
|
|
61
|
+
|
|
62
|
+
- **Intlayer**: Gelişmiş özelliklere ve optimizasyona ihtiyaç duyan profesyonel Solid uygulamaları için önerilen seçim (v8.7.12).
|
|
63
|
+
- **@solid-primitives/i18n**: Basit projeler için mükemmel hafif bir alternatif, ancak lazy loading gibi gelişmiş özelliklerden yoksundur.
|
|
64
|
+
- **solid-i18next**: Standart ancak ağır bir seçenek (~4.7x Intlayer), React i18next ile aynı dezavantajlara sahiptir.
|
|
65
|
+
- **Paraglide**: Yenilikçi yaklaşım ancak karmaşık DX ve bazı kurulumlarda tree-shaking sorunları.
|
|
66
|
+
|
|
67
|
+
## Uygulamanızı test edin
|
|
68
|
+
|
|
69
|
+
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.
|
|
70
|
+
|
|
71
|
+
<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
|
|
72
|
+
|
|
73
|
+
## Sorun
|
|
74
|
+
|
|
75
|
+
Çok dilli bir uygulamanın maliyetini sınırlamak için iki kaldıraç esastır:
|
|
76
|
+
|
|
77
|
+
- İçeriği sayfa / namespace bazında bölün, böylece ihtiyacınız olmadığında tüm sözlükleri yüklemezsiniz.
|
|
78
|
+
- Doğru dili dinamik olarak, yalnızca gerektiğinde yükleyin.
|
|
79
|
+
|
|
80
|
+
Bu yaklaşımların teknik sınırlarını anlamak:
|
|
81
|
+
|
|
82
|
+
**Dinamik yükleme**
|
|
83
|
+
|
|
84
|
+
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.
|
|
85
|
+
|
|
86
|
+
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.
|
|
87
|
+
|
|
88
|
+
**İçerik bölme (Splitting)**
|
|
89
|
+
|
|
90
|
+
`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.
|
|
91
|
+
|
|
92
|
+
## Araştırma Metodolojisi
|
|
93
|
+
|
|
94
|
+
Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
|
|
95
|
+
|
|
96
|
+
- `Base App` (i18n kütüphanesi yok)
|
|
97
|
+
- `solid-intlayer` (v8.7.12)
|
|
98
|
+
- `@solid-primitives/i18n` (v2.2.1)
|
|
99
|
+
- `solid-i18next` (v17.0.2)
|
|
100
|
+
- `@inlang/paraglide-js` (v2.17.0)
|
|
101
|
+
|
|
102
|
+
Framework, **10 sayfa** ve **10 dilden** oluşan çok dilli bir uygulamaya sahip `Solid`'dir.
|
|
103
|
+
|
|
104
|
+
**Dört yükleme stratejisini** karşılaştırdık:
|
|
105
|
+
|
|
106
|
+
| Strateji | Namespace yok (global) | Namespace var (kapsamlı/scoped) |
|
|
107
|
+
| :------------------ | :--------------------------------------------- | :----------------------------------------------------------------------- |
|
|
108
|
+
| **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ü. |
|
|
109
|
+
| **Dinamik yükleme** | **Dynamic**: Dil başına istek üzerine yükleme. | **Scoped dynamic**: Namespace ve dil başına hassas yükleme. |
|
|
110
|
+
|
|
111
|
+
## Strateji özeti
|
|
112
|
+
|
|
113
|
+
- **Static**: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük paket boyutu.
|
|
114
|
+
- **Dynamic**: Başlangıç ağırlığını azaltır (lazy-loading). Birçok diliniz olduğunda idealdir.
|
|
115
|
+
- **Scoped static**: Karmaşık ek ağ istekleri olmadan kodu düzenli tutar (mantıksal ayrım).
|
|
116
|
+
- **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.
|
|
117
|
+
|
|
118
|
+
## Detaylı sonuçlar
|
|
119
|
+
|
|
120
|
+
### 1 — Kaçınılması gereken çözümler
|
|
121
|
+
|
|
122
|
+
> Solid ekosisteminde kaçınılması gereken net bir çözüm yoktur.
|
|
123
|
+
|
|
124
|
+
### 2 — Kabul edilebilir çözümler
|
|
125
|
+
|
|
126
|
+
**(solid-i18next)** (`solid-i18next@17.0.2`):
|
|
127
|
+
|
|
128
|
+
`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.
|
|
129
|
+
|
|
130
|
+
Paket ağırdır (~14.6kb, bu da `solid-intlayer`'ın yaklaşık 4.7 katıdır).
|
|
131
|
+
|
|
132
|
+
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.
|
|
133
|
+
|
|
134
|
+
**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
|
|
135
|
+
|
|
136
|
+
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.
|
|
137
|
+
Ayrıca sayfa boyutu optimizasyonu için lazy loading ve kapsamlı namespace özellikleri de eksiktir.
|
|
138
|
+
|
|
139
|
+
**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
|
|
140
|
+
|
|
141
|
+
`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.
|
|
142
|
+
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.
|
|
143
|
+
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.
|
|
144
|
+
|
|
145
|
+
### 3 — Öneriler
|
|
146
|
+
|
|
147
|
+
**(Intlayer)** (`solid-intlayer@8.7.12`):
|
|
148
|
+
|
|
149
|
+
Kendi çözümüm olduğu için tarafsızlık adına `solid-intlayer`'ı kişisel olarak yargılamayacağım.
|
|
150
|
+
|
|
151
|
+
### Kişisel not
|
|
152
|
+
|
|
153
|
+
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.
|
|
154
|
+
|
|
155
|
+
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).
|
|
@@ -0,0 +1,148 @@
|
|
|
1
|
+
---
|
|
2
|
+
createdAt: 2026-04-20
|
|
3
|
+
updatedAt: 2026-04-21
|
|
4
|
+
title: 2026'da Svelte için En İyi i18n Çözümü - Benchmark Raporu
|
|
5
|
+
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.
|
|
6
|
+
keywords:
|
|
7
|
+
- benchmark
|
|
8
|
+
- i18n
|
|
9
|
+
- intl
|
|
10
|
+
- svelte
|
|
11
|
+
- performans
|
|
12
|
+
- intlayer
|
|
13
|
+
slugs:
|
|
14
|
+
- doc
|
|
15
|
+
- benchmark
|
|
16
|
+
- svelte
|
|
17
|
+
author: Aymeric PINEAU
|
|
18
|
+
applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
|
|
19
|
+
history:
|
|
20
|
+
- version: 8.7.12
|
|
21
|
+
date: 2026-01-06
|
|
22
|
+
changes: "Benchmark başlatıldı"
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
# Svelte i18n Kütüphaneleri — 2026 Benchmark Raporu
|
|
26
|
+
|
|
27
|
+
Bu sayfa, Svelte üzerindeki i18n çözümleri için bir benchmark raporudur.
|
|
28
|
+
|
|
29
|
+
## İçindekiler
|
|
30
|
+
|
|
31
|
+
<Toc/>
|
|
32
|
+
|
|
33
|
+
## İnteraktif Benchmark
|
|
34
|
+
|
|
35
|
+
<I18nBenchmark framework="vite-svelte" vertical/>
|
|
36
|
+
|
|
37
|
+
## Sonuç referansı:
|
|
38
|
+
|
|
39
|
+
<iframe
|
|
40
|
+
src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md"
|
|
41
|
+
width="100%"
|
|
42
|
+
height="600px"
|
|
43
|
+
style="border:none;">
|
|
44
|
+
</iframe>
|
|
45
|
+
|
|
46
|
+
> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
|
|
47
|
+
|
|
48
|
+
Tüm benchmark deposunu [burada](https://github.com/intlayer-org/benchmark-i18n/tree/main) görebilirsiniz.
|
|
49
|
+
|
|
50
|
+
## Giriş
|
|
51
|
+
|
|
52
|
+
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.
|
|
53
|
+
|
|
54
|
+
Uygulamanız büyüdükçe, bu sorun istemciye gönderilen JavaScript'i hızla büyütebilir ve navigasyonu yavaşlatabilir.
|
|
55
|
+
|
|
56
|
+
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.
|
|
57
|
+
|
|
58
|
+
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.
|
|
59
|
+
|
|
60
|
+
## TL;DR
|
|
61
|
+
|
|
62
|
+
- **Intlayer**: En küçük ayak izine sahip en performans odaklı seçim (v8.7.12).
|
|
63
|
+
- **Paraglide**: Tree-shaking için güçlü bir rakip ancak daha karmaşık bir geliştirici deneyimine ve reaktivite yüküne sahip.
|
|
64
|
+
- **svelte-i18n**: Svelte için kapsamlı ve standart, ancak çok daha büyük paket ağırlığı taşıyor (~7x Intlayer).
|
|
65
|
+
|
|
66
|
+
## Uygulamanızı test edin
|
|
67
|
+
|
|
68
|
+
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.
|
|
69
|
+
|
|
70
|
+
<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
|
|
71
|
+
|
|
72
|
+
## Sorun
|
|
73
|
+
|
|
74
|
+
Çok dilli bir uygulamanın maliyetini sınırlamak için iki kaldıraç esastır:
|
|
75
|
+
|
|
76
|
+
- İçeriği sayfa / namespace bazında bölün, böylece ihtiyacınız olmadığında tüm sözlükleri yüklemezsiniz.
|
|
77
|
+
- Doğru dili dinamik olarak, yalnızca gerektiğinde yükleyin.
|
|
78
|
+
|
|
79
|
+
Bu yaklaşımların teknik sınırlarını anlamak:
|
|
80
|
+
|
|
81
|
+
**Dinamik yükleme**
|
|
82
|
+
|
|
83
|
+
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.
|
|
84
|
+
|
|
85
|
+
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.
|
|
86
|
+
|
|
87
|
+
**İçerik bölme (Splitting)**
|
|
88
|
+
|
|
89
|
+
`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.
|
|
90
|
+
|
|
91
|
+
## Araştırma Metodolojisi
|
|
92
|
+
|
|
93
|
+
Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
|
|
94
|
+
|
|
95
|
+
- `Base App` (i18n kütüphanesi yok)
|
|
96
|
+
- `svelte-intlayer` (v8.7.12)
|
|
97
|
+
- `svelte-i18n` (v4.0.1)
|
|
98
|
+
- `@inlang/paraglide-js` (v2.17.0)
|
|
99
|
+
|
|
100
|
+
Framework, **10 sayfa** ve **10 dilden** oluşan çok dilli bir uygulamaya sahip `Svelte`'dir.
|
|
101
|
+
|
|
102
|
+
**Dört yükleme stratejisini** karşılaştırdık:
|
|
103
|
+
|
|
104
|
+
| Strateji | Namespace yok (global) | Namespace var (kapsamlı/scoped) |
|
|
105
|
+
| :------------------ | :--------------------------------------------- | :----------------------------------------------------------------------- |
|
|
106
|
+
| **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ü. |
|
|
107
|
+
| **Dinamik yükleme** | **Dynamic**: Dil başına istek üzerine yükleme. | **Scoped dynamic**: Namespace ve dil başına hassas yükleme. |
|
|
108
|
+
|
|
109
|
+
## Strateji özeti
|
|
110
|
+
|
|
111
|
+
- **Static**: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük paket boyutu.
|
|
112
|
+
- **Dynamic**: Başlangıç ağırlığını azaltır (lazy-loading). Birçok diliniz olduğunda idealdir.
|
|
113
|
+
- **Scoped static**: Karmaşık ek ağ istekleri olmadan kodu düzenli tutar (mantıksal ayrım).
|
|
114
|
+
- **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.
|
|
115
|
+
|
|
116
|
+
## Detaylı sonuçlar
|
|
117
|
+
|
|
118
|
+
### 1 — Kaçınılması gereken çözümler
|
|
119
|
+
|
|
120
|
+
> Svelte ekosisteminde kaçınılması gereken net bir çözüm yoktur.
|
|
121
|
+
|
|
122
|
+
### 2 — Kabul edilebilir çözümler
|
|
123
|
+
|
|
124
|
+
**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
|
|
125
|
+
|
|
126
|
+
`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.
|
|
127
|
+
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.
|
|
128
|
+
İş akışı ve DX de diğer seçeneklerden daha karmaşıktır.
|
|
129
|
+
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.
|
|
130
|
+
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.
|
|
131
|
+
|
|
132
|
+
> 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.
|
|
133
|
+
|
|
134
|
+
**(svelte-i18n)** (`svelte-i18n@3.4.0`):
|
|
135
|
+
|
|
136
|
+
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).
|
|
137
|
+
|
|
138
|
+
### 3 — Öneriler
|
|
139
|
+
|
|
140
|
+
**(Intlayer)** (`svelte-intlayer@8.7.12`):
|
|
141
|
+
|
|
142
|
+
Kendi çözümüm olduğu için tarafsızlık adına `svelte-intlayer`'ı kişisel olarak yargılamayacağım.
|
|
143
|
+
|
|
144
|
+
### Kişisel not
|
|
145
|
+
|
|
146
|
+
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.
|
|
147
|
+
|
|
148
|
+
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).
|
|
@@ -57,6 +57,13 @@ Pratikte, en az optimize edilmiş uygulamalar için uluslararasılaştırılmı
|
|
|
57
57
|
|
|
58
58
|
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.
|
|
59
59
|
|
|
60
|
+
## TL;DR
|
|
61
|
+
|
|
62
|
+
- **Intlayer**: TanStack Start için en iyi performansı ve en küçük paket boyutunu (v8.7.12) sağlar.
|
|
63
|
+
- **react-i18next** & **use-intl**: Geniş ekosistemlere sahip olgun alternatiflerdir, ancak optimize edilmeleri önemli ölçüde daha ağır ve karmaşıktır.
|
|
64
|
+
- **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.
|
|
65
|
+
- **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**.
|
|
66
|
+
|
|
60
67
|
## Uygulamanızı Test Edin
|
|
61
68
|
|
|
62
69
|
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
|
|
|
87
94
|
Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
|
|
88
95
|
|
|
89
96
|
- `Base App` (i18n kütüphanesi yok)
|
|
90
|
-
- `react-intlayer` (v8.7.
|
|
97
|
+
- `react-intlayer` (v8.7.12)
|
|
91
98
|
- `react-i18next` (v17.0.2)
|
|
92
99
|
- `use-intl` (v4.9.1)
|
|
93
100
|
- `@lingui/core` (v5.3.0)
|
|
94
101
|
- `@inlang/paraglide-js` (v2.15.1)
|
|
95
|
-
-
|
|
102
|
+
- `@tolgee/react` (v7.0.0)
|
|
96
103
|
- `react-intl` (v10.1.1)
|
|
97
104
|
- `wuchale` (v0.22.11)
|
|
98
105
|
- `gt-react` (vlatest)
|
|
@@ -150,7 +157,9 @@ Karşılaşılan sorunlar:
|
|
|
150
157
|
|
|
151
158
|
`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.
|
|
152
159
|
|
|
153
|
-
|
|
160
|
+
> 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.
|
|
161
|
+
|
|
162
|
+
**(Tolgee)** (`@tolgee/react@7.0.0`):
|
|
154
163
|
|
|
155
164
|
`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.
|
|
156
165
|
|
|
@@ -0,0 +1,160 @@
|
|
|
1
|
+
---
|
|
2
|
+
createdAt: 2026-04-20
|
|
3
|
+
updatedAt: 2026-04-21
|
|
4
|
+
title: 2026'da Vue için En İyi i18n Çözümü - Benchmark Raporu
|
|
5
|
+
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.
|
|
6
|
+
keywords:
|
|
7
|
+
- benchmark
|
|
8
|
+
- i18n
|
|
9
|
+
- intl
|
|
10
|
+
- vue
|
|
11
|
+
- performans
|
|
12
|
+
- intlayer
|
|
13
|
+
slugs:
|
|
14
|
+
- doc
|
|
15
|
+
- benchmark
|
|
16
|
+
- vue
|
|
17
|
+
author: Aymeric PINEAU
|
|
18
|
+
applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
|
|
19
|
+
history:
|
|
20
|
+
- version: 8.7.12
|
|
21
|
+
date: 2026-01-06
|
|
22
|
+
changes: "Benchmark başlatıldı"
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
# Vue i18n Kütüphaneleri — 2026 Benchmark Raporu
|
|
26
|
+
|
|
27
|
+
Bu sayfa, Vue üzerindeki i18n çözümleri için bir benchmark raporudur.
|
|
28
|
+
|
|
29
|
+
## İçindekiler
|
|
30
|
+
|
|
31
|
+
<Toc/>
|
|
32
|
+
|
|
33
|
+
## İnteraktif Benchmark
|
|
34
|
+
|
|
35
|
+
<I18nBenchmark framework="vite-vue" vertical/>
|
|
36
|
+
|
|
37
|
+
## Sonuç referansı:
|
|
38
|
+
|
|
39
|
+
<iframe
|
|
40
|
+
src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
|
|
41
|
+
width="100%"
|
|
42
|
+
height="600px"
|
|
43
|
+
style="border:none;">
|
|
44
|
+
</iframe>
|
|
45
|
+
|
|
46
|
+
> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
|
|
47
|
+
|
|
48
|
+
Tüm benchmark deposunu [burada](https://github.com/intlayer-org/benchmark-i18n/tree/main) görebilirsiniz.
|
|
49
|
+
|
|
50
|
+
## Giriş
|
|
51
|
+
|
|
52
|
+
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.
|
|
53
|
+
|
|
54
|
+
Uygulamanız büyüdükçe, bu sorun istemciye gönderilen JavaScript'i hızla büyütebilir ve navigasyonu yavaşlatabilir.
|
|
55
|
+
|
|
56
|
+
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.
|
|
57
|
+
|
|
58
|
+
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.
|
|
59
|
+
|
|
60
|
+
## TL;DR
|
|
61
|
+
|
|
62
|
+
- **Intlayer**: Yerel kapsam (scoping) ve dinamik yükleme ile en hafif çözüm (v8.7.12).
|
|
63
|
+
- **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.
|
|
64
|
+
- **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.
|
|
65
|
+
|
|
66
|
+
## Uygulamanızı test edin
|
|
67
|
+
|
|
68
|
+
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.
|
|
69
|
+
|
|
70
|
+
<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
|
|
71
|
+
|
|
72
|
+
## Sorun
|
|
73
|
+
|
|
74
|
+
Çok dilli bir uygulamanın maliyetini sınırlamak için iki kaldıraç esastır:
|
|
75
|
+
|
|
76
|
+
- İçeriği sayfa / namespace bazında bölün, böylece ihtiyacınız olmadığında tüm sözlükleri yüklemezsiniz.
|
|
77
|
+
- Doğru dili dinamik olarak, yalnızca gerektiğinde yükleyin.
|
|
78
|
+
|
|
79
|
+
Bu yaklaşımların teknik sınırlarını anlamak:
|
|
80
|
+
|
|
81
|
+
**Dinamik yükleme**
|
|
82
|
+
|
|
83
|
+
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.
|
|
84
|
+
|
|
85
|
+
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.
|
|
86
|
+
|
|
87
|
+
**İçerik bölme (Splitting)**
|
|
88
|
+
|
|
89
|
+
`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.
|
|
90
|
+
|
|
91
|
+
## Araştırma Metodolojisi
|
|
92
|
+
|
|
93
|
+
Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:
|
|
94
|
+
|
|
95
|
+
- `Base App` (i18n kütüphanesi yok)
|
|
96
|
+
- `vue-intlayer` (v8.7.12)
|
|
97
|
+
- `vue-i18n` (v11.4.0)
|
|
98
|
+
- `fluent-vue` (v3.8.2)
|
|
99
|
+
|
|
100
|
+
Framework, **10 sayfa** ve **10 dilden** oluşan çok dilli bir uygulamaya sahip `Vue`'dur.
|
|
101
|
+
|
|
102
|
+
**Dört yükleme stratejisini** karşılaştırdık:
|
|
103
|
+
|
|
104
|
+
| Strateji | Namespace yok (global) | Namespace var (kapsamlı/scoped) |
|
|
105
|
+
| :------------------ | :--------------------------------------------- | :----------------------------------------------------------------------- |
|
|
106
|
+
| **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ü. |
|
|
107
|
+
| **Dinamik yükleme** | **Dynamic**: Dil başına istek üzerine yükleme. | **Scoped dynamic**: Namespace ve dil başına hassas yükleme. |
|
|
108
|
+
|
|
109
|
+
## Strateji özeti
|
|
110
|
+
|
|
111
|
+
- **Static**: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük paket boyutu.
|
|
112
|
+
- **Dynamic**: Başlangıç ağırlığını azaltır (lazy-loading). Birçok diliniz olduğunda idealdir.
|
|
113
|
+
- **Scoped static**: Karmaşık ek ağ istekleri olmadan kodu düzenli tutar (mantıksal ayrım).
|
|
114
|
+
- **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.
|
|
115
|
+
|
|
116
|
+
### Neyi ölçtüm:
|
|
117
|
+
|
|
118
|
+
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.
|
|
119
|
+
|
|
120
|
+
- **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.
|
|
121
|
+
|
|
122
|
+
- **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.
|
|
123
|
+
|
|
124
|
+
- **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).
|
|
125
|
+
|
|
126
|
+
- **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.
|
|
127
|
+
|
|
128
|
+
- **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.
|
|
129
|
+
|
|
130
|
+
- **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).
|
|
131
|
+
|
|
132
|
+
- **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.
|
|
133
|
+
|
|
134
|
+
- **İ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.
|
|
135
|
+
|
|
136
|
+
- **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.
|
|
137
|
+
|
|
138
|
+
## Detaylı sonuçlar
|
|
139
|
+
|
|
140
|
+
### 1 — Kaçınılması gereken çözümler
|
|
141
|
+
|
|
142
|
+
> Vue ekosisteminde kaçınılması gereken net bir çözüm yoktur.
|
|
143
|
+
|
|
144
|
+
### 2 — Kabul edilebilir çözümler
|
|
145
|
+
|
|
146
|
+
**(vue-i18n)** (`vue-i18n@11.4.0`):
|
|
147
|
+
|
|
148
|
+
- **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.
|
|
149
|
+
|
|
150
|
+
Paket çok ağırdır (~24.3kb, bu da `vue-intlayer`'ın yaklaşık 9 katıdır).
|
|
151
|
+
|
|
152
|
+
**(fluent-vue)** (`fluent-vue@0.5.0`):
|
|
153
|
+
|
|
154
|
+
- **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).
|
|
155
|
+
|
|
156
|
+
### 3 — Öneriler
|
|
157
|
+
|
|
158
|
+
**(Intlayer)** (`vue-intlayer@8.7.12`):
|
|
159
|
+
|
|
160
|
+
Kendi çözümüm olduğu için tarafsızlık adına `vue-intlayer`'ı kişisel olarak yargılamayacağım.
|
package/docs/tr/configuration.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
createdAt: 2024-08-13
|
|
3
|
-
updatedAt: 2026-
|
|
3
|
+
updatedAt: 2026-05-12
|
|
4
4
|
title: Yapılandırma (Configuration)
|
|
5
5
|
description: Uygulamanız için Intlayer'ı nasıl yapılandıracağınızı öğrenin. Intlayer'ı ihtiyaçlarınıza göre özelleştirmek için çeşitli ayarları ve seçenekleri anlayın.
|
|
6
6
|
keywords:
|
|
@@ -14,6 +14,9 @@ slugs:
|
|
|
14
14
|
- concept
|
|
15
15
|
- configuration
|
|
16
16
|
history:
|
|
17
|
+
- version: 8.9.4
|
|
18
|
+
date: 2026-05-12
|
|
19
|
+
changes: "LM Studio sağlayıcısı için destek eklendi"
|
|
17
20
|
- version: 8.7.0
|
|
18
21
|
date: 2026-04-07
|
|
19
22
|
changes: "Derleme yapılandırmasına `minify` ve `prune` seçenekleri eklendi"
|
|
@@ -350,7 +353,7 @@ const config: IntlayerConfig = {
|
|
|
350
353
|
ai: {
|
|
351
354
|
/**
|
|
352
355
|
* Kullanılacak yapay zeka sağlayıcısı.
|
|
353
|
-
* Seçenekler: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai'
|
|
356
|
+
* Seçenekler: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai', 'lmstudio'
|
|
354
357
|
* Varsayılan: 'openai'
|
|
355
358
|
*/
|
|
356
359
|
provider: "openai",
|
|
@@ -916,16 +919,17 @@ Intlayer, maksimum esneklik için birden fazla yapay zeka sağlayıcısını des
|
|
|
916
919
|
- **Groq**
|
|
917
920
|
- **Amazon Bedrock**
|
|
918
921
|
- **Together.ai**
|
|
919
|
-
|
|
920
|
-
|
|
921
|
-
|
|
|
922
|
-
|
|
|
923
|
-
| `
|
|
924
|
-
| `
|
|
925
|
-
| `
|
|
926
|
-
| `
|
|
927
|
-
| `
|
|
928
|
-
| `
|
|
922
|
+
- **LM Studio**
|
|
923
|
+
|
|
924
|
+
| Alan | Açıklama | Tür | Varsayılan | Örnek | Not |
|
|
925
|
+
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
926
|
+
| `provider` | Intlayer yapay zeka özellikleri için kullanılacak sağlayıcı. | `'openai'` | <br/> `'anthropic'` | <br/> `'mistral'` | <br/> `'deepseek'` | <br/> `'gemini'` | <br/> `'ollama'` | <br/> `'openrouter'` | <br/> `'alibaba'` | <br/> `'fireworks'` | <br/> `'groq'` | <br/> `'huggingface'` | <br/> `'bedrock'` | <br/> `'googleaistudio'` | <br/> `'googlevertex'` | <br/> `'togetherai'` | <br/> `'lmstudio'` | `undefined` | `'anthropic'` | Farklı sağlayıcılar farklı API anahtarları gerektirir ve farklı fiyatlandırmalara sahiptir. |
|
|
927
|
+
| `model` | Yapay zeka özellikleri için kullanılacak model. | `string` | Yok | `'gpt-4o-2024-11-20'` | Belirli model sağlayıcıya göre değişir. |
|
|
928
|
+
| `temperature` | Yapay zeka yanıtlarının rastgeleliğini kontrol eder. | `number` | Yok | `0.1` | Daha yüksek sıcaklık = daha yaratıcı ve daha az tahmin edilebilir. |
|
|
929
|
+
| `apiKey` | Seçilen sağlayıcı için API anahtarınız. | `string` | Yok | `process.env.OPENAI_API_KEY` | Gizli tutulmalıdır; ortam değişkenlerinde saklayın. |
|
|
930
|
+
| `applicationContext` | Yapay zekanın daha doğru çeviriler üretmesine yardımcı olmak için uygulamanız hakkında ek bağlam (alan adı, hedef kitle, ton, terminoloji). | `string` | Yok | `'Kendi uygulama bağlamım'` | Kurallar eklemek için kullanılabilir (örneğin: `"URL'leri dönüştürmemelisiniz"`). |
|
|
931
|
+
| `baseURL` | Yapay zeka API'si için temel URL. | `string` | Yok | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Yerel veya özel bir yapay zeka API uç noktasına işaret edebilir. |
|
|
932
|
+
| `dataSerialization` | Yapay zeka özellikleri için veri serileştirme formatı. | `'json'` | <br/> `'toon'` | `undefined` | `'toon'` | • `'json'`: varsayılan, güvenilir; daha fazla token kullanır.<br/>• `'toon'`: daha az token, daha az tutarlı.<br/>• Modele bağlam olarak ek parametreler iletilir (akıl yürütme çabası vb.). |
|
|
929
933
|
|
|
930
934
|
---
|
|
931
935
|
|