Sürekli Yerelleştirme: Çevirileri Kod Tabanınızla Nasıl Senkronize Tutarsınız

Sürekli Yerelleştirme: Çevirileri Kod Tabanınızla Nasıl Senkronize Tutarsınız

Özet / Temel Çıkarımlar

• Sürekli yerelleştirme, çeviriyi yayın zamanındaki tek seferlik bir görev olarak değil, devam eden bir süreç adımı olarak ele alır — tıpkı CI/CD'nin testi ve dağıtımı ele aldığı gibi.
• Toplu çeviri iş akışları, yayın sıklığı arttıkça bozulur: dizeler eskir, birleştirme çakışmaları birikir ve çevirmenler bağlamı kaybeder.
• İşleyen bir sürekli yerelleştirme hattının altı aşaması vardır: kod değişikliği, dize çıkarma, çeviri tetikleyici, inceleme, birleştirme ve dağıtım. Her aşama farklı derecelerde otomatikleştirilebilir.
• Temel entegrasyon kalıpları, senkronizasyonu nasıl tetikledikleri bakımından farklılık gösterir: VCS'nizden webhook'lar, CI adımlarındaki CLI tabanlı push/pull komutları, yerel geliştirme için dosya izleyiciler ve dağıtımsız güncellemeler için OTA/CDN teslimatı.
• Bu sorunun her bölümünü tek başına çözen bir araç yoktur. Doğru kurulum; yayın sıklığınıza, dil sayısına, çevirmen iş akışına ve ürününüz için havadan güncellemenin önem taşıyıp taşımadığına bağlıdır.

Sürekli Yerelleştirme Nedir?

Sürekli yerelleştirme, çeviriyi yazılım geliştirme yaşam döngünüze her yayın döngüsünde bir kez gerçekleştirilen manuel bir adım olarak değil, sürekli ve otomatik bir süreç olarak entegre etme pratiğidir.

Neden önemli olduğunu anlamak için geleneksel yaklaşımla — genellikle toplu çeviri veya şelale çeviri olarak adlandırılan — karşıtlığı ele alalım. Toplu bir iş akışında şu adımlar gerçekleşir: bir geliştirici özelliği tamamlar, bir ürün yöneticisi tüm yeni dizeleri bir tabloya veya dışa aktarıma toplar, bir yerelleştirme yöneticisi bunları çevirmenlere (dahili veya harici) iletir, çeviriler günler veya haftalar sonra geri gelir, bir geliştirici bunları içe aktarır ve yayın en son tamamlanan yerel ayarı bekler. Bu döngü, yazılım üç ayda bir gönderildiğinde makul ölçüde işe yarıyordu. Ekipler haftada veya günlük olarak göndermeye başladığında bozuluyor.

CI/CD ile benzerlik doğrudandır. Sürekli entegrasyondan önce geliştiriciler uzun ömürlü dallarda çalışıyor, entegrasyon geç gerçekleşiyor ve birleştirme çakışmalarının maliyeti zamanla artıyordu. CI, entegrasyonu daha erken ve daha sık yaparak bu maliyeti dramatik biçimde azalttı. Sürekli yerelleştirme, çeviriler için aynı şeyi yapar: bir sprint boyunca dize değişikliklerini biriktirip bunları yayın zamanında uzlaştırmak yerine, her kod değişikliği çeviri hattını anında tetikler.

Bu çerçeve bazen sola kaydırılmış yerelleştirme olarak adlandırılır — sorunları erken yakalamak daha ucuz olduğu için testlere uygulanan aynı "sola kaydır" kavramı. Yazıldığı gün çeviri hattına giren bir dize, tam bağlamla, biriktirme baskısı olmadan ve yayını engelleme riski taşımadan çevrilir. Yayından bir gün önce hatta giren bir dize, baskı altında, çoğunlukla bağlam olmadan, 400 başka dizeyle birlikte toplu olarak ve ilk seferinde genellikle yanlış çevrilir.

Sürekli yerelleştirme, her dizenin saatler içinde çevrilip gönderildiği anlamına gelmez. Makine çevirisi bu boşluğu hız açısından doldurabilir; insan incelemesi sonrasında gelir. Yapısal olarak anlamı şudur: hat her zaman çalışır; yeni dizeler otomatik olarak akar, çevirmen kuyrukları artımlı olarak güncellenir ve çeviriler her aktarımı bir insanın organize etmesine gerek kalmadan kod tabanına veya teslimat katmanına geri akar.

Toplu Çeviri Neden Bozulur?

Toplu çeviri özünde yanlış değildir — seyrek gönderen veya az sayıda dizeyi yöneten projeler için makul bir yaklaşımdır. Ancak CI/CD hatlarındaki mühendislik ekipleri için toplu iş akışları dört özgün başarısızlık modu yaratır.

Yayın gecikmeleri. Çeviri gönderimin ön koşulu olduğunda ve çeviri, özellik dondurmasından sonra tetiklenen toplu bir görev olduğunda, yayın zaman çizelgesi çevirmen verimi tarafından kısıtlanır. Sürekli gönderen ekipler, beş iş günü süren bir yerelleştirme adımını kabul edemez. Yayın ya çevrilmemiş dizelerle gönderilir (kaynak dile, genellikle İngilizce'ye varsayılan olarak düşerek) ya da bekler — hiçbiri ölçekte kabul edilemez.

Çeviri eskimesi. Toplu bir modelde dizeler çoğunlukla halihazırda ilerlemiş bir kod tabanından dışa aktarılır. Çeviriler geldiğinde, dizelerin kendisi değişmiş olabilir — bir düğme etiketi yeniden ifade edilmiş, bir ekran yeniden tasarlanmış, bir özellik kaldırılmıştır. Çevirmenler güncel olmayan bir anlık görüntü üzerinde çalışır. Sonuç, canlı ürünle eşleşmeyen çeviriler veya atılıp yeniden yapılması gereken çeviri çalışmasıdır.

Çeviri dosyalarında birleştirme çakışmaları. Birden fazla geliştirici paralel olarak çalışırken ve çeviri dosyaları depoda (JSON, YAML, XLIFF veya benzeri olarak) bulunduğunda, bu dosyalardaki eşzamanlı değişiklikler birleştirme çakışmaları üretir. Uygulama mantığındaki çakışmaların aksine, çeviri dosyası çakışmaları çözmesi sıkıcı ve hata eğilimlidir: iki dal da yeni anahtarlar eklemiş, bir anahtarı silmiş, bir anahtarı farklı bir şeye yeniden adlandırmıştır. Toplu ne kadar büyükse, çakışmalar o kadar kötüdür.

Geliştirici-çevirmen sürtüşmesi. Toplu bir iş akışında, geliştirici ile çevirmen arasındaki aktarım; zaman baskısı altında bozulan geleneklere dayanan manuel, çoğunlukla eşzamansız bir süreçtir. Geliştiriciler dışa aktarmayı unutur. Çevirmenlere bağlam olmadan dosyalar verilir. Dışa aktarma ile içe aktarma arasında anahtarlar yeniden adlandırılır. İçe aktarmalar, çevirmenlerin doğrudan yaptığı değişikliklerin üzerine yazar. Bu başarısızlıkların hiçbiri tek başına yıkıcı değildir — ancak birikir. Zamanla sürtüşme, ekiplerin yerelleştirme kalitesini öncelik dışı bırakmasına neden olur ve yerelleştirme borcu, teknik borçla aynı şekilde birikir.

Sürekli Yerelleştirme Hattı

Sürekli bir yerelleştirme hattı, dize değişikliklerini altı aşamadan geçirir. Hat, insan kararıyla değil, bir kod değişikliğiyle tetiklenir. Her aşama, bir sonraki aşamanın manuel müdahale olmaksızın tüketebileceği deterministik bir çıktı üretir.

Kod değişikliği
    |
    v
Dize çıkarma
    |
    v
Çeviri tetikleyici
    |
    v
Çeviri (MT + insan incelemesi)
    |
    v
Depoya geri birleştirme (veya CDN'ye push)
    |
    v
Dağıtım (veya CDN tabanlıysa OTA güncelleme)

Aşama 1: Kod değişikliği. Bir geliştirici, kod tabanında çevrilebilir bir dize ekler, değiştirir veya kaldırır. İyi bir i18n kurulumunda bu, bir anahtar-değer dosyasını (JSON, YAML, XLIFF) güncellemek veya çalışma zamanında çözülen bir kod anahtar başvurusu eklemek anlamına gelir.

Aşama 2: Dize çıkarma. Hat, mevcut durumu önceki çıkarma anlık görüntüsüyle karşılaştırarak hangi dizelerin yeni, değiştirilmiş veya silinmiş olduğunu belirler. Bu genellikle yerelleştirme aracının CLI'ı veya bir CI betiği tarafından işlenir. Çıktı, dize değişikliklerinin bir farkıdır — tüm dizelerin tam dışa aktarımı değil, yalnızca delta. Her çalıştırmada farklar yerine tam dışa aktarmalar hesaplayan araçlar, gereksiz çevirmen çalışması yaratır ve yeni dizelere öncelik vermeyi zorlaştırır.

Aşama 3: Çeviri tetikleyici. Yeni ve değiştirilmiş dizeler çeviri yönetim sistemine (TMS) gönderilir. Bu; bir webhook aracılığıyla (VCS olayı TMS'ye bir API çağrısı tetikler), bir CI adımıyla (başarılı bir derlemeden sonra dize farkını ileten bir CLI komutu) veya bir dosya izleyiciyle (geliştirme sırasında yerel bir ajan dosya değişikliklerini izler ve sürekli olarak senkronize eder) gerçekleşebilir. Tetikleyici otomatik olmalıdır — bu adımı başlatması için bir insan gerektirmek toplu sorununu yeniden ortaya çıkarır.

Aşama 4: Çeviri. Çevirmenler (insan veya makine ya da kombinasyon) TMS'deki yeni dizeler üzerinde çalışır. İyi tasarlanmış sistemler, çevirmenlerin ileri geri iletişime gerek kalmadan doğru çeviriler üretmesine yardımcı olmak için ekran görüntüleri, bileşen bağlamı, karakter sınırları ve bitişik dizeler sağlar. Makine çevirisi otomatik olarak taslaklar üretebilir; insan incelemeciler doğruluk, marka sesi ve bağlama duyarlı düzeltmelere odaklanır.

Aşama 5: Birleştirme. Tamamlanan çeviriler, yönetim modelinize bağlı olarak bir pull request olarak depoya geri gönderilir veya doğrudan bir çeviri dalına işlenir. OTA özellikli platformlar için bu adım, çevrilmiş dizeleri bir CDN veya API uç noktasına iter — teslimat yolu için depoyu tamamen atlayarak.

Aşama 6: Dağıtım. Dosya tabanlı teslimat için çeviriler bir sonraki derlemede paketlenir ve uygulamayla birlikte dağıtılır. CDN tabanlı teslimat için çeviriler kenarda zaten canlıdır — uygulama bunları yeni bir dağıtım olmadan bir sonraki istekte alır.

Temel tasarım ilkesi şudur: 2'den 5'e kadar olan aşamalar, makine tarafından çevrilen içerik için kaliteyi artıran ancak teslimatı engellemeyen isteğe bağlı bir katman olarak insan incelemesiyle tamamen otomatikleştirilmelidir. İnsan incelemesi eşzamansız olmalıdır: önce MT çevirisini yayınlayın, hazır olduğunda incelenmiş çeviriyle değiştirin.

Entegrasyon Kalıpları

Kod tabanınızı çeviri hattınıza nasıl bağladığınız, yukarıdakilerin gerçekte ne kadarının otomatikleştirilebileceğini belirler. Her biri farklı değiş tokuşlara sahip dört temel entegrasyon kalıbı vardır.

VCS webhook. Depo barındırma platformunuz (GitHub, GitLab, Bitbucket), bir işleme veya pull request oluşturulduğunda TMS'ye bir HTTP olayı gönderir. TMS yükü ayrıştırır, hangi dosyaların değiştiğini belirler, yeni dizeleri çıkarır ve bunları çeviri için kuyruğa alır. Bu, CI hattınızda herhangi bir değişiklik gerektirmez ve main'e birleşmeden önce dallarda bile çalışır. Sınırlama, TMS'nin dosya formatınızı ve proje yapınızı anlaması gerektiğidir — yapılandırma, kod tabanınızda değil TMS tarafında yapılır.

CI adımı (CLI). CI hattınız, yeni dizeleri göndermek ve isteğe bağlı olarak çevrilmiş dizeleri çekmek için TMS CLI'ını çalıştıran bir adım içerir. Bu en esnek kalıptır çünkü betik, derleme bağlamına tam erişimle CI ortamınızda çalışır. GitHub Actions marketplace ve GitLab CI, büyük TMS platformlarının çoğu için resmi veya topluluk tarafından korunan aksiyonlar içerir. Değiş tokuş, CLI sürümünü, kimlik doğrulama kimlik bilgilerini gizli olarak ve push/pull adımlarının derleme adımlarına göre sıralamasını yönetmeniz gerekmesidir.

Dosya izleyici. Yerel bir daemon, çeviri dosyası dizinlerinizi izler ve siz kod yazarken değişiklikleri gerçek zamanlı olarak TMS ile senkronize eder. Bu öncelikle bir geliştirici deneyimi aracıdır: çevirmenler, bir CI çalıştırmasını beklemek yerine bir geliştirici ekledikten saniyeler içinde yeni dizeleri görür. Daemon'ın çalışıyor olmasına bağlı olduğu ve ekip genelinde tutarlı yerel kurulum gerektirdiği için üretim hattı mekanizması olarak uygun değildir.

OTA / CDN teslimatı. Çevrilmiş dizeleri depoya işleyip bir dağıtımda paketlemek yerine, uygulama çevirileri çalışma zamanında bir CDN veya API'den alır. Çeviriler için yapılan güncellemeler, yeni bir derleme veya dağıtım olmaksızın anında küresel olarak kullanılabilir. Bu kalıp, uygulamanın çalışma zamanı çeviri yüklemesi için tasarlanmış olmasını gerektirir — ki bu modern i18n kütüphanelerinin çoğunda standarttır — ve CDN'e çalışma zamanı bağımlılığı getirir. UI dizeleri için en operasyonel çevik kalıptır.

Üretim kurulumlarının çoğu kalıpları birleştirir: TMS'yi kod tabanıyla senkronize tutmak için bir CI adımı (veya webhook) ile yeni bir dağıtım gerektirmeyen dize güncellemeleri için CDN teslimatı.

Dikkat Edilmesi Gereken Temel Özellikler

Tüm yerelleştirme platformları gerçek sürekli yerelleştirmeyi desteklemez. Araçları değerlendirirken, bir platformun manuel çeviri portalı olarak kullanılmak yerine gerçekten bir CI/CD hattına entegre edilip edilemeyeceğini belirleyen özellikler bunlardır.

Yeni ve değiştirilmiş dizelerin otomatik algılanması. Platform, manuel dışa aktarma gerektirmeden bir dosya farkından veya VCS olayından dize değişikliklerini otomatik olarak tanımlamalıdır. Her değişiklikte tam bir dosyayı dışa aktarmanızı ve yeniden içe aktarmanızı gerektiren platformlar, sürekli iş akışları için tasarlanmamıştır.

Çevirmen bağlamı. Dizeleri izole olarak çeviren çevirmenler, dizenin UI'da nerede göründüğünü görebilenlerden daha düşük kaliteli çeviriler üretir. En iyi platformlar, ekran görüntülerini, bileşen meta verilerini veya dizenin gerçek üründe işlenmiş halini gösteren bağlamda düzenlemeyi kabul eder. Bağlam olmadan, "Kaydet", "Görüntüle" veya "İptal" gibi kısa dizeler, bağlamın dışında anlamları belirsiz olduğu için düzenli olarak yanlış çevrilir.

Dal desteği. Ekibiniz özellik dalları kullanıyorsa, yerelleştirme platformunuz VCS dallarınızı yansıtan çeviri dallarını desteklemelidir. Bir özellik dalındaki dizeler, dal main'e birleşmeden önce çevrilebilir olmalıdır — aksi takdirde çeviriler her zaman en az bir birleştirme döngüsü kadar kod gerisinde kalır.

Test için sözde yerelleştirme. Sözde yerelleştirme, gerçek çeviri olmaksızın çevrilmiş metni simüle etmek için kaynak dizelerdeki karakterleri görsel olarak benzer genişletilmiş Latin karakterlerle değiştirir. Gerçek çeviriler mevcut olmadan önce, geliştirmenin erken aşamalarında düzen hatalarını — metin taşması, kesik etiketler, sabit kodlanmış genişlik varsayımları — yakalar. Otomatik sözde yerel ayar oluşturmayı destekleyen bir platform, geliştirmenin herhangi bir noktasında herhangi bir yerel ayarda UI testi yapılmasını sağlar.

Yeniden dağıtım olmadan havadan (OTA) güncellemeler. Bir çeviriyi güncellemek için yeni bir derleme göndermek çok yavaş veya çok maliyetli olan uygulamalar için — mobil uygulamalar, masaüstü uygulamaları veya yüksek frekanslı web uygulamaları — OTA teslimatı zorunludur. Platform, düşük gecikme süresiyle küresel olarak dağıtılmış bir kenar önbelleğinden çeviriler sunmalı ve çeviriler yayınlandığında otomatik önbellek geçersiz kılma işlemi yapmalıdır.

Çeviri belleği ve tutarlılık uygulaması. Çeviri belleği, daha önce çevrilmiş dizeleri projeler ve bağlamlar genelinde yeniden kullanarak çevirmen çabasını azaltır ve tutarlılığı artırır. Tutarlılık uygulaması, daha önce çevrilmiş bir terimle eşleşen ancak farklı şekilde çevrilmiş dizelere işaret eder — büyük bir projede terminoloji sürükünü yakalar.

Yaygın Tuzaklar

Sürekli yerelleştirme hatları, manuel iş akışı sorunlarından farklı özgün başarısızlık modları getirir. Bunlar en yaygın olanlardır.

QA katmanı olmadan aşırı otomatikleştirme. Tamamen otomatik makine çevirisi hatları, yüksek hızda çeviriler gönderebilir. Aynı zamanda yüksek hızda hatalı çeviriler de gönderebilirler. Herhangi bir insan incelemesi olmayan makine çevirisi, dahili araçlar ve düşük riskli UI dizeleri için uygundur. Müşteriye yönelik pazarlama metni, yasal açıklamalar, hata mesajları veya marka sesini yansıtan her şey için insan inceleme adımı isteğe bağlı değildir. Hattınızı şu şekilde tasarlayın: MT çevirilerini hemen yedek olarak yayınlayın, insan tarafından incelenmiş çevirilerle eşzamansız olarak değiştirin — insan incelemesinde yayını engellemeyin, ancak tüm içerik için MT'yi nihai olarak kabul etmeyin.

Çevirmenler için bağlamı görmezden gelmek. Bağlam aktarımını otomatikleştirmeden dize aktarımını otomatikleştirmek, düşük kaliteli çeviriler üreten hızlı bir hat yaratır. checkout.button.primary gibi bir dize anahtarı, ekran görüntüsü, açıklama veya karakter sınırı olmadan bir çevirmene neredeyse hiçbir şey söylemez. Bağlam teslimatını hattınıza başından itibaren ekleyin — sonradan uyarlamak çok daha zordur.

Anahtar yeniden adlandırmalarıyla çeviri belleğini bozmak. Çeviri belleği, platforma bağlı olarak çevirileri kaynak dizelere veya dize anahtarlarına eşler. Geliştiriciler anahtarları yeniden adlandırdığında — örneğin user.save_button'ı profile.save_changes olarak değiştirdiğinde — TMS bunu çoğunlukla silinmiş bir anahtar ve yeni, çevrilmemiş bir anahtar olarak ele alır. O dize için önceki tüm çeviri çalışmaları TM'den kaybolur. Bir anahtar yeniden adlandırma politikası oluşturun: anahtar yeniden adlandırmalarını kullanımdan kaldırılmış-ve-oluştur işlemi olarak ele alın (çeviriler onaylanana kadar eski anahtarı saklayın) veya yalnızca anahtar adı yerine içerik karması kullanarak anahtar değişiklikleri arasında dize kimliğini izleyen bir TMS kullanın.

Silinmiş anahtarları yönetmemek. Kaynaktan bir dize kaldırıldığında, çoğu platform çevirilerini TMS'de süresiz olarak bırakır. Zamanla bu, depolama alanını boşa harcayan, çevirmenleri karıştıran ve çeviri tamamlanma raporlamasını yanlış yapan yetim çeviriler yaratır. Kaynakta artık mevcut olmayan anahtarlar için çevirileri kaldıran bir CI betiği veya TMS otomasyon kuralı aracılığıyla düzenli bir temizleme döngüsü uygulayın.

Tüm yerel ayarları aynı şekilde ele almak. Farklı yerel ayarlar, çevirmen kullanılabilirliğine, dil çifti karmaşıklığına ve inceleme gereksinimlerine bağlı olarak farklı çeviri hızlarına sahiptir. Tüm yerel ayarların çeviriyi tamamlamasını bekleyen bir hat sıklıkla en yavaş yerel ayar tarafından engellenir. Hattınızı hazır olan çevrilmiş yerel ayarlarla dağıtacak şekilde tasarlayın ve hazır olmayan yerel ayarlar için kaynak dile geri düşün — bir yerel ayar tanımladığınız bir tamamlanma eşiğinin altına düştüğünde uyarıyla birlikte.

Sürekli Yerelleştirmeyi Destekleyen Araçlar

Bunlar, mühendislik odaklı sürekli yerelleştirme hatlarında en yaygın kullanılan araçlardır. Her birinin dürüst güçlü yönleri ve gerçek sınırlamaları vardır.

Crowdin CLI. Crowdin'in komut satırı istemcisi, yerel entegrasyonlar ve webhook desteği aracılığıyla GitHub, GitLab ve Bitbucket ile sıkı sıkıya entegre olur. Dallamayı destekler, geniş bir dosya format kütüphanesine sahiptir (JSON, YAML, XLIFF, Android XML, iOS Strings ve diğerleri) ve güçlü bir çeviri belleği sunar. CI entegrasyonu iyi belgelenmiştir. Sınırlamalar: dallanma modeli karmaşık monorepo'lar için yapılandırması kafa karıştırıcı olabilir ve OTA teslimatı, daha yüksek plan katmanlarında bulunan Crowdin OTA özelliğini gerektirir.

Transifex. Transifex, CLI'ı ve webhook'ları aracılığıyla uzun süredir CI/CD entegrasyon desteğine sahiptir. Web tabanlı OTA teslimatı için "Live Translation" özelliğini tanıttı — metin düğümlerine müdahale eden ve bunları bir CDN'den çevrilmiş içerikle değiştiren bir JavaScript parçacığı. Bu yaklaşım, derleme hattını kolayca değiştiremeyecek ekipler için kullanışlı olan uygulama derleme sürecinde herhangi bir değişiklik gerektirmez. Live yaklaşımının DOM düzeyinde çalıştığı için performans değiş tokuşları vardır.

Lokalise CI. Lokalise, güçlü GitHub Actions ve GitLab CI entegrasyonuna, çeviri incelemesi için iyi tasarlanmış bir katkıda bulunma iş akışına sahiptir ve iOS, Android ve web için SDK'ları aracılığıyla OTA'yı destekler. Dallanma desteği çoğu rakipten daha cilalidir. Web editörünün iyi ekran görüntüsü tabanlı bağlam desteği vardır. Lokalise genellikle bunu yansıtan fiyatlandırmayla orta-kurumsal pazara konumlandırılmıştır.

Phrase CLI (eski adıyla Phrase Strings). Phrase (eski adıyla Memsource ve PhraseApp, şimdi birleşik bir marka altında) kapsamlı bir CLI'ya, güçlü XLIFF desteğine (XLIFF iş akışlarını tercih eden profesyonel çeviri ajanslarıyla çalışan ekipler için kullanışlı) ve olgun çeviri belleği ile kalite güvencesi özelliklerine sahiptir. Profesyonel çeviri ajansı iş akışlarında özellikle güçlüdür. CI entegrasyonu sağlamdır ancak VCS yerel otomasyon için Crowdin veya Lokalise'den daha fazla yapılandırma gerektirir.

Better i18n. Better i18n, bir CLI, React/Next.js/Vue/Svelte SDK'ları ve Cloudflare'in kenar ağı üzerinden CDN tabanlı teslimat ile geliştirici odaklı bir yaklaşım benimser. OTA modeli, çeviri güncellemelerinin yeni bir derleme veya dağıtım tetiklemeden yayınlandıktan saniyeler içinde küresel olarak kullanılabilir olduğu anlamına gelir. Yapay zeka destekli ilk taslak çevirileri destekler ve çevirileri kod tabanına yakın yönetmek isteyen mühendislik ekiplerine yöneliktir. CLI aracılığıyla CI entegrasyonu basittir. 2026 başı itibarıyla Crowdin, Lokalise veya Phrase'den daha erken aşamadadır; XLIFF iş akışları ve kurumsal SSO gibi alanlarda daha dar bir özellik setine sahiptir.

SSS

S: Çevirmenlerimiz teknik değilse sürekli yerelleştirme kullanabilir miyiz?

Evet. Hat otomasyonu mühendislik tarafındadır. Çevirmenler yalnızca TMS web arayüzüyle etkileşime girer; burada dizeleri bir çeviri editöründe görürler — YAML dosyaları veya Git komutları değil. Otomasyon; dizeleri koddan çıkarmayı, TMS'ye göndermeyi ve çevirileri geri birleştirmeyi yönetir. Çevirmen deneyimi büyük ölçüde TMS editörünün kalitesiyle ve sağladığınız bağlamla belirlenir, hat mekaniğiyle değil.

S: Henüz birleşmemiş özellik dallarını nasıl yönetiriz?

Çoğu TMS platformu, VCS dallarını yansıtan çeviri dallarını destekler. Bir dal eşlemesi yapılandırırsınız — örneğin feat/* ile eşleşen özellik dalları, karşılık gelen TMS dallarıyla senkronize olur. Çevirmenler, dal birleşmeden önce bir özellik dalındaki dizeler üzerinde çalışabilir. VCS'nizde dal birleştiğinde, TMS dalı da birleşir ve çeviriler aktarılır. Bu, açıkça dallamayı destekleyen bir TMS gerektirir — her platform bunu yapmaz.

S: Çeviriler depoda mı yoksa TMS'de mi tutulmalı?

İdeali her ikisinde. Depo, kaynak dizeler (geliştiricilerin yazdığı dizeler) için gerçeğin kaynağıdır. TMS, çevrilmiş dizeler için gerçeğin kaynağıdır. Hattınız bunlar arasında senkronizasyon yapar: kaynak dizeler depodan TMS'ye akar, çevrilmiş dizeler TMS'den depoya (veya bir CDN'ye) geri akar. Çevrilmiş dizeleri yalnızca TMS olmadan depoda saklamak, geliştirici olmayan kişilerin katkıda bulunmasını zorlaştırır. Bunları yalnızca TMS'de depoya senkronize etmeden saklamak, derlemeleri deterministik olarak yeniden oluşturmayı zorlaştırır.

S: Yerelleştirme hattımızın sağlığını nasıl ölçeriz?

Bu dört metriği takip edin: çeviri kapsamı (yerel ayar başına çevirisi olan kaynak dize yüzdesi), çeviri gecikmesi (bir dizenin kaynağa eklenmesinden ilk çevirisinin yayınlanmasına kadar geçen süre), inceleme biriktirmesi (insan incelemesini bekleyen makine tarafından çevrilmiş dize sayısı) ve yetim anahtar oranı (TMS'de artık kaynakta mevcut olmayan anahtarlar için çeviriler). Sağlıklı bir hat; yüksek kapsama, düşük gecikme, yönetilebilir inceleme biriktirmesi ve sıfıra yakın yetim anahtar oranına sahiptir.

S: Küçük bir ekip için asgari düzeyde uygulanabilir sürekli yerelleştirme kurulumu nedir?

Web ürünü gönderen iki ila beş mühendisten oluşan bir ekip için: main'e her birleşmede yeni kaynak dizeleri göndermek için TMS CLI'ını çalıştıran tek bir CI adımı, ilk taslaklar için etkinleştirilmiş makine çevirisi ve en müşteri odaklı dizeler için haftalık bir çevirmen inceleme oturumu. Bu tek başına yayını engelleyen toplu çeviriyi ve birleştirme çakışmalarının çoğunu ortadan kaldırır. Ürün ve çevirmen iş akışı olgunlaştıkça OTA teslimatı ve dallanma desteği daha sonra eklenebilir.

Sonuç

Sürekli yerelleştirme, CI/CD düşüncesinin ürününüzün çeviri katmanına mantıksal uzantısıdır. Temel öngörü şudur: çeviri bir yayın dönüm noktası değil, bir hat aşamasıdır. Dizeler çıkarıldığında, çevirmenlere iletildiğinde, incelendiğinde ve normal geliştirme akışınızın bir parçası olarak otomatik olarak birleştirildiğinde, toplu iş akışlarında yerelleştirmeyi ağrılı yapan maliyetler — yayın gecikmeleri, eski çeviriler, birleştirme çakışmaları, geliştirici-çevirmen sürtüşmesi — mühendislik çözümleri olan mühendislik sorunlarına indirgenir.

Bu makalede açıklanan hat varsayımsal değildir. Düzinelerce yerel ayara gönderen şirketlerdeki ekipler, üretimde bu varyantlarını çalıştırır. Ayrıntılar değişir — hangi TMS, hangi CI sistemi, OTA teslimatının kapsama girip girmediği, ne kadar insan incelemesinin gerektiği — ancak yapı tutarlıdır: mekanik çalışmayı otomatikleştirin, insan çalışması için bağlam sağlayın ve çeviri tamamlanmasını ikili bir yayın kapısı olarak değil sürekli bir metrik olarak ele alın.

Ekibiniz için en az sürtüşmeli değişiklikle başlayın: her main dalı birleşmesinde yeni dizeleri TMS'nize ileten bir CI adımı. Oradan, dallanma desteği, bağlam teslimatı, OTA güncellemeleri ve otomatik kalite kontrollerini artımlı olarak ekleyin. Her katman, tam bir hat yeniden inşası gerektirmeden sürtüşmeyi azaltır ve kaliteyi artırır.

Hedef, geliştiriciler için görünmez bir yerelleştirme iş akışıdır — yeni bir yerel ayara göndermenin bir proje değil, bir yapılandırma değişikliği olduğu bir iş akışı.

Kaynaklar

[^1]: Martin Fowler, "Continuous Integration," martinfowler.com, https://martinfowler.com/articles/continuousIntegration.html

[^2]: W3C Internationalization Working Group, "Internationalization Best Practices for Spec Developers," W3C Working Group Note, https://www.w3.org/TR/international-specs/

[^3]: OASIS XLIFF Technical Committee, "XLIFF Version 2.1," OASIS Standard, https://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html

[^4]: GitHub Actions documentation, "Events that trigger workflows," https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

[^5]: GitLab CI/CD documentation, "GitLab CI/CD pipeline configuration reference," https://docs.gitlab.com/ee/ci/yaml/

[^6]: Unicode CLDR Project, "Unicode Common Locale Data Repository," https://cldr.unicode.org/

[^7]: IETF BCP 47, "Tags for Identifying Languages," https://www.rfc-editor.org/rfc/rfc5646

[^8]: Crowdin documentation, "CLI tool," https://developer.crowdin.com/cli-tool/

[^9]: Lokalise documentation, "CI/CD integrations," https://lokalise.com/blog/continuous-localization/

[^10]: Phrase documentation, "Phrase Strings CLI," https://support.phrase.com/hc/en-us/articles/5784095916188

Son güncelleme: Mart 2026