İçindekiler
Ekibiniz için yerelleştirme araçlarını değerlendirme görevi size verildiyse, muhtemelen şunu fark etmişsinizdir: TMS pazarı oldukça kafa karıştırıcı. Pazarlama sayfaları "sorunsuz iş akışları" ve "yapay zeka destekli çeviri" vaat ediyor ama çevirilerin uygulamanıza nasıl aktarıldığı, kimin ne ödediği ya da geçişin ne kadar zahmetli olacağı hakkında neredeyse hiçbir şey söylemiyor.
Bu rehber tam da bunu ele alıyor. Bir TMS'in gerçekte ne yaptığını (ve ne yapmadığını), karşılaşacağınız üç mimari modeli, 10 kriterlik bir değerlendirme kontrol listesini ve durumunuza uygun kategoriyi seçmenize yardımcı olacak bir karar çerçevesini ele alacağız.
Bir TMS Gerçekte Ne Yapar (ve Ne Yapmaz)
Bir çeviri yönetim sistemi, kaynak içeriğiniz ile son kullanıcılarınız arasında konumlanır. Özünde üç sorunu çözer:
- Neyin çevrilmesi gerektiğini takip etmek — yeni dizeler, değişen dizeler, silinen dizeler
- Kimin neyi çevireceğini koordine etmek — çevirmenleri atamak, inceleme iş akışlarını yönetmek
- Çevrilmiş içeriği iletmek — nihai çevirileri uygulamanıza entegre etmek
Mühendislik ekiplerinin büyük çoğunluğu #3'e yoğunlaşırken #1 ve #2'yi göz ardı eder. Bu bir hatadır. Bir TMS'in takip ve koordinasyon konusunda yetersiz kaldığı noktalar, genellikle yerelleştirme birikimlerinin oluştuğu yerlerdir.
Bir TMS'in yapmadığı şeyler — bazı satıcıların ima ettiğinin aksine: kaynak kodunuzun yerini almaz, uygulamanızı otomatik olarak çok dilli hale getirmez ve yüksek riskli içeriklerde insan incelemesi ihtiyacını ortadan kaldırmaz. Yapay zeka çevirisi dramatik biçimde iyileşti, ancak "uygulama mağazası açıklaması için yeterince iyi" ile "hukuki belge için yeterince iyi" birbirinden farklı standartlardır.
Üç TMS Mimarisi
Teslim modelini anlamak, yapacağınız en önemli mimari karardır. Piyasadaki her TMS, üç kategoriden birine girer.
Dosya-Senkronizasyonlu TMS
En eski ve en yaygın model. Uygulamanız, /locales veya /public/lang gibi bir dizinde yerel ayar dosyaları (JSON, YAML, PO vb.) içerir. TMS bu dosyaları çeker, çeviri için gönderir ve çevrilmiş dosyaları bir senkronizasyon mekanizmasıyla (genellikle bir CLI aracı, GitHub entegrasyonu veya CI/CD adımı) reponuza geri gönderir.
Pratikte nasıl çalışır: En son çevirileri almak için tms pull çalıştırırsınız, commit edersiniz ve deploy edersiniz. Ya da TMS, belirli aralıklarla güncellenmiş yerel ayar dosyalarıyla bir PR açar.
Artıları:
- Her stack ile çalışır — uygulamanız bir dosya okuyabiliyorsa çalışır
- Anlaması ve denetlemesi kolay — çeviriler repodaki sıradan dosyalardır
- Olgun araç seti ve geniş ekosistemler
- Harici bir servise çalışma zamanı bağımlılığı yok
Eksileri:
- Yerel ayar dosyaları hızla büyür ve gürültülü diff'ler oluşturur
- Çeviri güncellemeleri bir deploy döngüsü gerektirir
- Branching stratejileri karmaşık hale gelir — "gerçek" çeviriler hangi branch'te?
- Birden fazla dosyada anahtar yönetimi hata yapmaya açık hale gelir
- Tür güvenliği yok — eksik veya yeniden adlandırılmış anahtarlar çalışma zamanında sessizce başarısız olur
API-First TMS
Dosya senkronizasyonu yerine, uygulamanız çalışma zamanında bir TMS API uç noktasından çevirileri alır. Bu, yerel ayar dosyalarını reponuzdan kaldırır. TMS bir çalışma zamanı bağımlılığı haline gelir.
Pratikte nasıl çalışır: Uygulama başlangıcında (veya her istekte), istemciniz GET /translations?locale=de&namespace=checkout gibi bir API çağrısı yapar. TMS, mevcut çevirileri içeren bir JSON nesnesi döndürür.
Artıları:
- Çeviri güncellemeleri anlıktır — deploy gerekmez
- Yerel ayar dosyaları repoyu kirletmez
- Çok sayıda anahtarı yönetmek daha kolaydır
Eksileri:
- Dikkatli bir önbellekleme yapılmazsa soğuk başlangıç gecikmesi oluşur
- Çalışma zamanında ağ bağımlılığı — TMS kesintisi uygulamanızı bozabilir
- Önbellekleme stratejileri sizin sorununuzdur
- SDK kalitesi büyük ölçüde değişir — tür güvenliği genellikle yoktur
- İstek başına fiyatlandırma modelleri ölçekte pahalıya patlayabilir
CDN-First TMS
API-first'in teslimat avantajlarını statik dosyaların performans özellikleriyle birleştiren daha yeni bir mimari. Çeviriler derlenir ve CDN'e değiştirilemez, sürümlü paketler olarak yayınlanır. Uygulamanız bir yerel ayar paketini bir kez (genellikle başlangıçta veya yerel ayar değişiminde) alır ve agresif biçimde önbelleğe alır.
Pratikte nasıl çalışır: TMS'e yayınlarsınız, bu da bir paket derleyerek edge konumlara gönderir. Uygulamanız https://cdn.example.com/v42/de.json adresini alır ve oturum boyunca kullanır. URL yapısı, önbellek geçersiz kılmayı deterministik hale getirir.
Artıları:
- Repoda yerel ayar dosyası yok
- Çeviriler yayınlandığında anlık önbellek geçersiz kılma
- Tahmin edilebilir, düşük gecikmeli teslimat — CDN edge, API'nizden daha hızlıdır
- Çeviri güncellemeleri deploy gerektirmez
- SDK'lar şemadan oluşturulabilir, bu da tür güvenliğini mümkün kılar
Eksileri:
- Dosya senkronizasyonuna kıyasla biraz daha karmaşık zihinsel model
- Paket sürümleme stratejisi biraz planlama gerektirir
- Dosya-senkronizasyonlu araçlara kıyasla daha az olgun ekosistem
TMS Değerlendirme İçin 10 Kriter
Değerlendirmenizi yaparken bu kontrol listesini kullanın. Her adayı her kriter için 1–5 arasında puanlayın.
1. Geliştirici İş Akışı Entegrasyonu
TMS, ekibinizin mevcut çalışma şekline uyuyor mu? Şunlara bakın: yerel Git entegrasyonu (PR tabanlı iş akışları, branch tespiti), CI/CD pipeline'larında çalışan bir CLI ve framework'ünüzü (React, Vue, Swift, Android vb.) anlayan çıkarma araçları.
Kırmızı bayrak: TMS entegrasyonu, mevcut pipeline'ınızda olmayan ayrı bir deployment adımı gerektiriyorsa, bu adım atlanacaktır.
2. Çeviri Teslimat Modeli
Hangi mimariyi kullanıyor? Gereksinimlerinizle eşleştirin: deploy olmadan anlık güncellemelere ihtiyacınız varsa, dosya senkronizasyonu işe yaramaz. Çeviri yüklemesi için P99 gecikmenizin 50ms altında olması gerekiyorsa, önbelleğe alınmamış bir API-first yaklaşımı da işe yaramaz. Satıcılara özellikle şunu sorun: "Çeviriler sisteminizden adım adım üretim uygulamasına nasıl gidiyor?"
3. Yapay Zeka Çeviri Yetenekleri
Burada geniş bir spektrum var. Bir uçta: ham makine çevirisi (dizeleri sadece bir MT sağlayıcısına gönderme). Diğer uçta: kullanıcı arayüzünüzü anlayan, sözlüğünüzü uygulayan, yer tutucuları doğru işleyen ve marka sesinize göre ayarlanabilen bağlam duyarlı çeviri.
Temel sorular:
- Yapay zeka çevirisi sözlüğünüze ve çeviri belleğinize saygı gösteriyor mu?
- Hedef dillerin çoğulluk kurallarını yönetebiliyor mu?
- Dizelerdeki dinamik değişkenleri nasıl işliyor (örn.
Hello, {name})?
4. Tür Güvenliği ve SDK Kalitesi
Mühendislik ekipleri için bu, çoğunlukla eksik bir çeviri anahtarından kaynaklanan ilk çalışma zamanı çökmesine kadar göz ardı edilir. İyi SDK'lar, çeviri şemanızdan türler oluşturur; böylece t('checkout.cta.button') çalışma zamanında değil, derleme zamanında başarısız olur.
SDK'yı şu açılardan değerlendirin: TypeScript desteği, anahtar otomatik tamamlama, çoğul yönetimi, interpolasyon tür güvenliği ve framework'e özgü entegrasyonlar.
5. Fiyatlandırma Modeli Şeffaflığı
TMS fiyatlandırması kötü şöhretiyle opaktır. Yaygın modeller:
- Kullanıcı başına (editörler/çevirmenler)
- Çevrilen kelime başına (MT veya insan)
- Anahtar başına (yönetilen dize sayısı)
- Platform ücreti + kullanım
Gerçek rakamlarınıza dayalı somut bir tahmin alın: kaç anahtar, kaç yerel ayar, kaç çevirmen, ayda kaç kelime çevriliyor. Ardından limiti aştığınızda ne olacağını sorun.
Bunu nasıl ele aldığımız için fiyatlandırma sayfamıza bakın.
6. Sözlük ve Çeviri Belleği
Çeviri belleği (TM), tutarlı dizelerin iki kez çevrilmemesi için önceki çevirileri saklar. Sözlük uygulaması, marka terimlerinin, ürün adlarının ve teknik terminolojinin yanlış çevrilmemesini sağlar.
Bu özellikler hem para tasarrufu sağlar hem de tutarlılığı artırır. Satıcılara sorun: "'Dashboard'ı bir bağlamda çevirirsem, bu tüm yerel ayarlarda otomatik olarak yeniden kullanılır mı?"
7. İşbirliği Özellikleri
Şirket içi çevirmenleriniz varsa veya bir yerelleştirme ajansıyla çalışıyorsanız, TMS'in onların iş akışını da desteklemesi gerekir. Şunlara bakın: görsel editör (gerçek kullanıcı arayüzü bağlamında çevirileri düzenleme), inceleme/onay iş akışları, belirli anahtarlar üzerinde yorum dizileri ve rol tabanlı erişim kontrolü.
Ekibiniz yalnızca geliştiricilerden oluşuyorsa ve yapay zeka çevirisi + harici inceleme kullanıyorsanız, burada hafif araçlar yeterlidir. Kullanmayacağınız kurumsal işbirliği özellikleri için fazladan ödeme yapmayın.
8. Ölçeklenebilirlik
Mevcut ölçeğinizin 10 katında TMS nasıl görünüyor? Özellikle:
- Anahtarlar: 100.000'den fazla çeviri anahtarıyla performans nasıl düşüyor?
- Yerel ayarlar: Hedef dil sayısında pratik bir sınır var mı?
- Ekip büyüklüğü: Ayrı ekiplerle birden fazla proje/ad alanını yönetebiliyor musunuz?
- İstek hacmi: API-first veya CDN-first modeldeyseniz, verim sınırları neler?
9. Geçiş Çabası
TMS sağlayıcısı değiştirmek zahmetlidir. Taahhüt etmeden önce maliyeti konusunda dürüst olun. Şunları değerlendirin:
- Yeni TMS mevcut yerel ayar dosyalarınızı veya TM'yi içe aktarabilir mi?
- SDK geçiş yolu nedir? Kod tabanınız genelinde çeviri çağrı noktalarını değiştirmeyi gerektirecek mi?
- Geçiş sırasında kesinti süresi var mı?
- Mevcut sözlük ve TM verilerinize ne olacak?
10. Satıcı Kilitleme Riski
Bu, geçiş çabasıyla ilgilidir ancak kendi kriteri olmayı hak ediyor. Sorun: "İki yıl içinde platformunuzdan ayrılmak istersem, ne götürürüm?" Çeviri belleğinizi, sözlüğünüzü ve tüm çevrilmiş içeriğinizi standart formatlarda dışa aktarabilmelisiniz. Yanıt belirsizse, bu bir sinyaldir.
Karşılaştırma Tablosu
| Kriter | Dosya-Senkronizasyonlu TMS | API-First TMS | CDN-First TMS |
|---|---|---|---|
| Geliştirici iş akışı | Git-dostu, PR tabanlı | API/SDK odaklı | Git + SDK, tür güvenli |
| Çeviri teslimi | Deploy gerekli | Çalışma zamanı API çağrısı | CDN paketi, edge önbellekli |
| Güncelleme hızı | Yavaş (deploy döngüsü) | Anlık | Anlık |
| Çalışma zamanı bağımlılığı | Yok | Yüksek | Düşük (önbellekli paket) |
| Tür güvenliği | Nadir | Mümkün | Yerel (şema güdümlü) |
| Repoda yerel ayar dosyaları | Evet | Hayır | Hayır |
| Yapay zeka çevirisi | Değişken | Değişken | Bağlam duyarlı |
| Gecikme | Yok (paketlenmiş) | Önbelleklemeye bağlı | Düşük (edge CDN) |
| Anahtar ölçekleme | Gürültülü olur | Genel olarak iyi | Genel olarak iyi |
| Kilitleme riski | Orta | Orta–Yüksek | Satıcıya bağlı |
Karar Çerçevesi
Hızlı gelişen ve minimum yerelleştirme karmaşıklığına sahip küçük bir ekipseniz, dosya senkronizasyonu muhtemelen yeterlidir. Basit, iyi anlaşılmış ve sıfır çalışma zamanı bağımlılığına sahip. Acı, birçok yerel ayar ve sık çeviri güncellemesiyle birlikte sonradan gelir.
Deploy olmadan anlık çeviri güncellemelerine ihtiyacınız varsa ve çalışacak bir API bütçeniz varsa, API-first bir adım ileriye gider. Sadece bir güvenilirlik bağımlılığı oluşturmadığınızdan emin olun — TMS API'nizin sabahın 2'sinde kullanılamaz hale gelmesi artık sizin nöbet probleminizdir.
TypeScript kullanan modern bir frontend uygulaması geliştiriyorsanız, etkileşime hızlı başlangıç süresi istiyorsanız ve çeviri güncellemelerinin deploy pipeline'ınızdan bağımsız olarak yayınlanmasını istiyorsanız, ekosistemi CDN-first yönüne doğru ilerliyor. Tür güvenliği, edge teslimatı ve deploy bağımsızlığının kombinasyonunu bir kez deneyimledikten sonra tartışmak güç olur.
3–4 yerel ayarın ötesine geçmiş bir ekibi değerlendiren bir mühendislik müdürüysenz ve repodaki yerel ayar dosyalarının, yavaş çeviri deploy'larının ve üretimde eksik anahtar hatalarının acısını yaşamaya başladıysanız — bu, tam olarak TMS mimarisini değiştirmenin karşılığını verdiği kırılma noktasıdır. Sadece aynı mimari içinde yükseltme yapmayın. Her üçünü de değerlendirin.
Farklı mimarilerin pratikte nasıl karşılaştırıldığını karşılaştırma sayfalarımızda görün veya geliştirici odaklı özellikler hakkında okuyun.
Geçiş Değerlendirmeleri: Geçmeden Önce Sorulacak Sorular
Yeni bir TMS'e bağlanmadan önce satıcıyla bu kontrol listesini gözden geçirin:
Veri taşınabilirliği
- Tüm çevrilmiş dizeleri TMX veya XLIFF formatında dışa aktarabilir miyim?
- Sözlüğümü standart CSV veya TBX dosyası olarak dışa aktarabilir miyim?
- [Mevcut aracımdan] içe aktarma için bir geçiş kılavuzu var mı?
SDK geçişi
- İstemci SDK'sını değiştirmek nasıl görünüyor? Doğrudan bir yedek mi yoksa çeviri çağrı noktalarının tam yeniden yazılması mı?
- Bir codemod veya geçiş betiğiniz var mı?
- Aşamalı bir dağıtım sırasında her iki SDK'yı paralel olarak çalıştırabilir miyim?
Geçiş
- Her iki sistemin aynı anda aktif olduğu bir dönem var mı?
- Süreçteki içeriği nasıl yönetiyorsunuz (çeviri için gönderilmiş ama henüz döndürülmemiş dizeler)?
Geçiş sırasında fiyatlandırma
- Geçiş deneme süresi var mı?
- İki sistem için ödeme yaptığım paralel çalışma aşamasında maliyet modeli nedir?
Sonuç
TMS pazarı modern frontend mimarisine henüz yetişemedi. Çoğu araç, yerel ayar dosyalarının repoda yaşadığını, bir deploy'un çeviri güncellemesi için kabul edilebilir bir yol olduğunu ve "tür güvenliği"nin anahtar adlandırma kuralınızı README'de belgeleme anlamına geldiğini varsayıyor.
Bu varsayım 2015'te mantıklıydı. Frontend'inizin CDN'e deploy edilmiş statik bir paket olduğu, ekibinizin günde birden fazla kez gönderim yaptığı ve eksik bir çeviri anahtarının yerelleştirilmiş bir pazar için ödeme akışını sessizce bozabileceği bir dünyada geçerliliğini yitirmiştir.
Araçları değerlendirirken teslimat modeliyle başlayın. Diğer her şey — yapay zeka kalitesi, işbirliği özellikleri, fiyatlandırma — şuna ikincildir: çeviriler uygulamama gerçekte nasıl giriyor ve ne kadar hızlı?
CDN-first bir yaklaşımın pratikte nasıl göründüğünü görmek istiyorsanız, özelliklerimizi keşfedin veya muhtemelen zaten değerlendirdiğiniz araçlarla nasıl karşılaştırıldığımıza bakın.
Better i18n, modern frontend ekipleri için geliştirilmiş, geliştirici öncelikli bir yerelleştirme platformudur. Tür güvenli SDK'lar, Git tabanlı iş akışları, CDN teslimatı ve sözlük uygulamalı yapay zeka çevirisi — repoda yerel ayar dosyaları olmadan.
