Lokalizasyon ve Çeviri Yönetimi İçin Web Uygulaması Nasıl Oluşturulur

Web Uygulamasının Çözmesi Gerekenler

Lokalizasyon yönetimi, ürününüzün metinlerinin (bazen görseller, tarih, para birimi ve formatlama kuralları da) çevrilmesi, incelenmesi, onaylanması ve yayınlanmasının günlük işidir—build'i bozmadan veya kullanıcıları şaşırtmadan.

Bir ürün ekibi için amaç "her şeyi çevirmek" değil. Amaç, ürün değiştikçe her dil versiyonunu doğru, tutarlı ve güncel tutmaktır.

Çözdüğünüz sorunlar

Çoğu ekip iyi niyetle başlar ama sonunda karmakarışık olur:

• Dağınık locale dosyaları: repolar, klasörler ve elektronik tablolar arasında tek bir doğruluk kaynağı yok.
• Tutarsız ifade (ör. "Sign in" vs "Log in"), tekrar eden stringler ve aynı kavram için farklı çeviriler.
• Yavaş inceleme döngüleri çünkü geri bildirim e-posta zincirlerinde, yorumlarda veya sohbet mesajlarında kalır.
• Belirsiz durum: kimse neyin çevrildiğini, neyin eski olduğunu ve neyin yayınlanmaya uygun olduğunu bilmiyor.
• Riskli manuel adımlar: dosya dışa/ileme işlemleri eksik anahtarlar, kırık yer tutucular veya yanlış üstüne yazmalara yol açar.

Uygulama kimler için

Yararlı bir lokalizasyon yönetim web uygulaması birden fazla rolü desteklemelidir:

• Geliştiriciler güvenilir string güncellemeleri, temiz diff'ler ve daha az merge çatışması ister.
• Çevirmenler bağlam, terminoloji rehberi ve odaklanmış bir iş sırası ister.
• İnceleyiciler açık bir onay akışı ve belirli stringler üzerinde yorum yapabilme ister.
• PM'ler ve lokalizasyon liderleri güvenilir ilerleme görünürlüğü ve güvenilir teslim tarihlerine ihtiyaç duyar.

Sonunda ne inşa edeceksiniz

MVP, stringleri merkezileştiren, locale başına durumu izleyen ve temel inceleme ile dışa aktarmayı destekleyen bir sistem olacaktır. Daha dolu bir sistem otomasyon (senkronizasyon, QA kontrolleri), zengin bağlam ve sözlük ile çeviri hafızası gibi araçlar ekler.

Kapsamı ve MVP Özelliklerini Tanımlayın

Tabloları veya ekranları tasarlamadan önce, lokalizasyon yönetim web uygulamanızın gerçekten ne için sorumlu olduğunu belirleyin. Sıkı bir kapsam ilk sürümü kullanılabilir kılar ve her şeyi yeniden inşa etmenizi önler.

İçerik türlerini listeleyerek başlayın

Çeviriler nadiren tek yerde yaşar. İlk günden itibaren desteklemeniz gerekenleri yazın:

• UI stringleri (ürün etiketleri, butonlar, hata mesajları)
• Transaction e-postaları (konular ve şablonlar)
• Doküman snippet'leri (kısa tekrar kullanılabilir bloklar)
• Pazarlama sayfaları (genellikle farklı onay ihtiyaçları olan farklı bir ekip tarafından yönetilir)

Bu liste, "tek iş akışı her şeye uyar" yaklaşımından kaçınmanıza yardımcı olur. Örneğin pazarlama metinleri onaya ihtiyaç duyabilirken UI stringleri hızlı iterasyon gerektirir.

Hangi dosya formatlarını destekleyeceğinizi kararlaştırın

MVP için 1–2 format seçin, sonra genişletin. Yaygın seçenekler JSON, YAML, PO ve CSV. Pratik bir MVP tercihi uygulama stringleri için JSON veya YAML, gerekirse CSV sadece elektronik tablo import'ları için eklemek olabilir.

Çoğul formlar, iç içe anahtarlar ve yorumlar gibi gereksinimleri açıkça belirtin. Bu ayrıntılar locale dosya yönetimini ve gelecekteki import/export güvenilirliğini etkiler.

Yerelleri ve fallback kurallarını seçin

Bir kaynak dil (çoğunlukla en) tanımlayın ve fallback davranışını belirleyin:

• Eksik stringler ene geri döner
• İsteğe bağlı olarak bir üst locale'e fall back (örn. pt-BR → pt → en)

Ayrıca bir locale için "tamam"un ne anlama geldiğini karar verin: %100 çevirildi mi, incelendi mi yoksa yayınlandı mı.

MVP vs sonraki özellikler

MVP için çeviri inceleme sürecine ve temel i18n iş akışına odaklanın: string oluştur/düzenle, işi ata, incele ve dışa aktar.

Daha sonra ekleyeceğiniz özellikler: ekran görüntüleri/bağlam, sözlük, çeviri hafızası, makine çevirisi entegrasyonu—ancak çekirdek iş akışınızı gerçek içerikle doğrulayana kadar bunları inşa etmeyin.

Veri Modelini Tasarlayın

Bir çeviri uygulaması veri modeline bağlı olarak başarır veya başarısız olur. Temel varlıklar ve alanlar netse, UI, iş akışı ve entegrasyonlar daha basit olur.

Temel varlıklarla başlayın

Çoğu ekip küçük bir tablo seti ile ihtiyaçlarının %80'ini karşılayabilir:

• Project: bir ürün/uygulama veya belirli bir string alanı.
• Locale: diller ve bölgesel varyantlar (örn. en, en-GB, pt-BR).
• Key: kodda kullanılan sabit tanımlayıcı (checkout.pay_button).
• Source string: bir key'e bağlı referans metin (genellikle temel dil).
• Translation: bir key + locale için yerelleştirilmiş değer.
• Version: sürümler, importlar veya dosya revizyonları için anlık görüntü sınırı.

İlişkileri açıkça modelleyin: bir Project'in birçok Locale'i vardır; bir Key bir Project'e aittir; bir Translation bir Key ve bir Locale'e aittir.

Durum alanlarıyla iş akışını kodlayın

Her çeviriye bir durum ekleyin ki sistem insanlara rehberlik edebilsin:

• draft → in_review → approved
• Yasal inceleme veya eksik bağlam gibi durumlar için blocked

Durum değişikliklerini olay (event) veya bir geçmiş tablosu olarak tutun ki "kim bunu ne zaman onayladı" sorusuna cevap verebilesiniz.

Hataları önleyen meta verileri saklayın

Çeviriler yalnızca düz metin değildir. Şunları yakalayın:

• Placeholders (örn. {name}, %d) ve bunların kaynağa uyma gerekliliği
• Maksimum uzunluk (butonlar ve UI kısıtları için)
• Kontekst notları (nerede göründüğü, anlam, ton)
• Etiketler (özellik alanı, platform, aciliyet)

Denetim alanlarını atlamayın

En azından şu bilgileri saklayın: created_by, updated_by, zaman damgaları ve kısa bir change_reason. Bu, incelemeleri hızlandırır ve ekibin uygulamada neyin yayımlandığıyla karşılaştırma yaparken güven oluşturur.

Depolama ve Versiyonlamayı Planlayın

Depolama kararları düzenleme UX'ini, import/export hızını, diff alma ve güvenle yayınlama yeteneğini etkiler.

String saklama: satır başına key mi yoksa dosya başına belge mi

Row-per-key (her locale için her string bir DB satırı) gösterge panoları ve iş akışları için iyidir. "Fransızcada eksik" ya da "inceleme gerekli" gibi filtreler kolaydır. Dezavantajı: locale dosyası oluşturmak için gruplama ve sıralama gerekir; dosya yolu ve namespace için ekstra alanlara ihtiyaç olur.

Document-per-file (her locale dosyasını JSON/YAML belge olarak saklamak) repolarla daha uyumlu çalışır ve dışa aktarmayı hızlandırır. Ancak arama ve filtreleme zorlaşır, bu yüzden anahtar, statü ve meta veriler için bir indeks gerekebilir.

Birçok ekip hibrit kullanır: kaynak olarak row-per-key, dışa aktarma için üretilmiş dosya snapshot'ları.

Versiyonlama: çeviri ve sürüm düzeyinde revizyonlar

Her değişiklik şu bilgileri kaydetmeli: önceki değer, yeni değer, yazar, zaman damgası ve yorum. Bu, inceleme ve rollback işlemlerini basitleştirir.

Ayrıca release snapshot'ları tutun: "v1.8'de ne yayınlandı" gibi. Bir snapshot, locale'ler arasında onaylanmış revizyonların tutarlı bir setine işaret eden bir etiket olabilir.

Çoğul ve cinsiyet kuralları

Çoğulü tek bir boolean olarak ele almayın. ICU MessageFormat veya CLDR kategorilerini kullanın (örn. one, few, many, other) ki Lehçe veya Arapça gibi diller İngilizce kurallara zorlanmasın.

Cinsiyet ve diğer varyasyonlar için bunları aynı key'in varyantları olarak modelleyin; böylece çevirmenler tüm bağlamı görür.

Ölçeklenen arama ve filtreler

Key, kaynak metin, çeviri ve geliştirici notları üzerinde tam metin arama uygulayın. Bunu şu filtrelerle eşleştirin: status, tags, file/namespace ve missing/empty.

Bu alanları erken indeksleyin—arama kullanıcıların günde yüzlerce kez kullandığı bir özelliktir.

Ölçeklenen Bir Mimari Seçin

Lokalizasyon yönetim uygulamaları genellikle basit başlar—dosya yükle, string düzenle, tekrar indir. Ancak çok sayıda ürün, yerel, sık sürümler ve otomasyon eklenince karmaşıklaşır.

Esnek kalmanın en kolay yolu endişeleri erken ayırmaktır.

Pratik bir yığın

Ortak ve ölçeklenebilir bir kurulum: API + web UI + arka plan işleri + veritabanı:

• Web UI: çeviri editörü, inceleme ekranları, proje ayarları.
• API: UI, CLI araçları ve entegrasyonlar tarafından kullanılan tek gerçek kaynak.
• Arka plan işleri: import/export, QA taramaları, sync gibi uzun süren işler.
• Veritabanı: projeler, key'ler, çeviriler, geçmiş ve izinler.

Bu ayrım ağır iş yükleri için ekstra worker eklemeyi kolaylaştırır.

Eğer ilk çalışan sürümü hızlıca elde etmek istiyorsanız, Koder.ai gibi bir platform React UI, Go API ve PostgreSQL şemasını yapılandırmaya yardımcı olabilir—sonrasında kaynak kodu dışa aktarabilirsiniz.

API yapısını nasıl düzenlemeli

API'yi birkaç ana kaynak etrafında tutun:

• Projects: uygulama/ürün konteyneri.
• Locales: proje başına etkin diller.
• Keys: sabit tanımlayıcılar (örn. checkout.button.pay).
• Translations: key+locale başına gerçek metin, statü, yazar, zaman damgaları.

Listeleme uç noktalarını hem insan düzenlemesine hem de otomasyona hizmet edecek şekilde filtre kabul edecek biçimde tasarlayın, örn: "locale'de eksik", "değiştiğinden beri" veya "inceleme gereken".

Gerekli arka plan işleri

Otomasyonu asenkron olarak ele alın. Kuyruk tipik olarak şunları işler:

• Importlar (locale dosyalarını parçala, doğrula, key oluştur/güncelle)
• Exportlar (sürüm için locale paketleri oluştur)
• QA kontrolleri (yer tutucular, uzunluk, HTML, yasaklı terimler)
• Sync işler (Git, CI veya diğer sistemlere pull/push)

İşleri idempotent yapın ve proje başına iş logları kaydedin ki ekipler hataları kolayca teşhis edebilsin.

Erken önem taşıyan performans temelleri

Küçük ekipler bile büyük veri setleri üretebilir. Listeler için sayfalandırma, yaygın okumalarda önbellekleme (proje locale istatistikleri) ve import/export uç noktalarını korumak için rate limit uygulamak önemlidir.

Bunlar, adoptasyon büyüdüğünde çeviri yönetim sisteminizin yavaşlamasını önleyen sıkıcı ama gerekli detaylardır.

Kimlik Doğrulama Rolleri ve İzinler Ekleyin

Uygulamanız kaynak stringleri ve çeviri geçmişini saklıyorsa erişim kontrolü isteğe bağlı değildir—kaza ile düzenlemeleri önlemek ve kararları izlenebilir kılmak için gereklidir.

Gerçek işlere uyan roller seçin

Basit bir rol seti çoğu ekip için yeterlidir:

• Admin: organizasyon ayarları, yereller, entegrasyonlar ve kullanıcı erişimi.
• Developer: kaynak stringleri düzenler, key oluşturur, import/export başlatır.
• Translator: atanmış yerellerde çevirileri düzenler.
• Reviewer: çevirileri onaylar veya reddeder, nihai sözdizimini kilitler.
• Viewer: paydaşlar için salt okunur erişim.

Sadece başlık değil, izinler tanımlayın

Her eylemi bir izin olarak ele alın ki ileride kolayca evrilebilsin. Yaygın kurallar:

• Kaynağı düzenleme: yalnızca Admin, Developer
• Onaylama: Reviewer (ve isteğe bağlı olarak Admin)
• Dışa aktarma: Developer/Admin veya release sahibi Reviewer
• Yerel yönetimi: yalnızca Admin
• Çevirileri düzenleme: atanan locale(ler) içinde Translator/Reviewer

Bu, çeviri yönetim sistemini esnek ama güvenli tutar.

Giriş: SSO vs e-posta

Google Workspace, Azure AD veya Okta kullanıyorsanız SSO parola riskini azaltır ve dışlama işlemlerini hızlı yapar. Küçük ekipler için e-posta/parola çalışır—güçlü parolalar ve reset akışı zorunlu olsun.

Oturum güvenliği temelleri

Kısa ömürlü, güvenli oturumlar (HTTP-only cookie), CSRF koruması, rate limit ve mümkünse 2FA kullanın.

Sorumluluk için etkinlik günlükleri

Kim neyi ve ne zaman değiştirdiğini kaydedin: düzenlemeler, onaylar, yerel değişiklikleri, dışa aktarmalar ve izin güncellemeleri. Geçmişle birlikte "geri al" özelliği sunun ki rollback güvenli ve hızlı olsun.

Çekirdek UI Ekranlarını Oluşturun

UI lokalizasyon işinin gerçekten yapıldığı yerdir; bu yüzden geri dönüşleri azaltan ve durumu hemen anlaşılır kılan ekranlara öncelik verin.

1) Proje genel bakışı (kontrol odası)

Bir panoyu üç soruyu hızlıca cevaplayacak şekilde başlatın: ne tamamlandı, ne eksik ve ne engellendi.

Locale başına ilerlemeyi gösterin (yüzde çevirildi, yüzde incelendi) ve net bir "eksik string" sayısı ekleyin. İnceleme kuyruğu widget'ı beklemede olan öğeleri vurgulasın ve son değişiklikler feed'i inceleyicilerin riskli düzenlemeleri fark etmesini sağlasın.

Filtreler grafiklerden daha önemlidir: locale, ürün alanı, statü, atanan kişi ve "son sürümden beri değişenler".

2) Çeviri editörü (hızlı, bağlamsal, denetlenebilir)

İyi bir editör yan yana olmalı: sol kaynak, sağ hedef ve bağlam her zaman görünür.

Bağlamda key, ekran görüntüsü metni (varsa), karakter limitleri ve yer tutucular görünmeli. Geçmiş ve yorumlar aynı görünümde olsun ki çevirmenler ayrı bir tartışma ekranına ihtiyaç duymasın.

Durum akışını tek tıklama yapın: Draft → In review → Approved.

3) Toplu işlemler (yöneticiler ve liderler için)

Lokalizasyon işi çoğunlukla "çok küçük değişiklik"lerden oluşur. Çoklu seçim ile atama, statü değiştirme ve bir locale ya da modül için export/import gibi toplu eylemler ekleyin.

Toplu eylemleri rollere göre kısıtlayın.

4) Erişilebilirlik ve klavye kısayolları

Yoğun çevirmenler editörde saatler geçirir. Tam klavye navigasyonu, görünür odak durumları ve şu kısayollar olsun:

• Sonraki/önceki string
• Kaydet ve "In review" olarak işaretle
• Kaynağı hedefe kopyala

Ekran okuyucular ve yüksek kontrast modu desteği ekleyin—erişilebilirlik herkesin hızını artırır.

Çeviri İş Akışı Oluşturun

Bir lokalizasyon yönetim uygulamasının kaderini iş akışı belirler. İnsanlar sırada neyi çevirip kimin karar verdiğini bilmiyorsa gecikmeler ve kalite sorunları olur.

Atama akışı: kim neyi ve ne zamana kadar çevirir

İşi açık birim olarak tanımlayın: belirli bir sürüm için bir locale'de bir dizi key. Proje yöneticileri işleri locale, dosya/modül ve önceliğe göre atayabilsin, isteğe bağlı teslim tarihi ekleyin.

Atamaları "İşim" gelen kutusunda görünür kılın: atanmış ne var, ne gecikmiş ve ne başkalarını mı bekliyor. Büyük ekipler için iş yükü sinyalleri (öğe sayısı, kelime hesabı tahmini, son aktivite) ekleyin.

İnceleme akışı: yorumlar, öneriler, onaylar ve reddetmeler

Basit bir statü hattı oluşturun, örn: Untranslated → In progress → Ready for review → Approved.

İnceleme sadece ikili bir kontrol olmasın. Satır içi yorumlar, önerilen düzenlemeler ve onay/reddetme ile neden gösterme desteklenmeli. Reddetme sırasında geçmiş korunmalı—üzerine yazılmasın.

Bu, inceleme sürecinizi denetlenebilir kılar ve tekrar hataları azaltır.

Çakışma yönetimi: kaynak değişiklikleri ve needs update bayrakları

Kaynak metin değişecektir. Değiştiğinde mevcut çevirileri "Needs update" olarak işaretleyin ve bir diff veya "ne değişti" özeti gösterin. Eskİ çeviriyi referans olarak tutun ama yeniden onaylanmadan tekrar onaylanmasını engelleyin.

Bildirimler: atama ve inceleme istekleri için e-posta/in-app

İlerlemeyi engelleyen olaylarda bildirim gönderin: yeni atama, inceleme isteği, reddetme, yaklaşan teslim tarihi ve onaylı stringleri etkileyen kaynak değişikliği.

Bildirimleri eyleme geçirilebilir tutun ve ilgili sayfaya derin bağlantılar sağlayın, örn: /projects/{id}/locales/{locale}/tasks.

Import, Export ve Senkronizasyonu Otomatize Edin

Manuel dosya yönetimi lokalizasyon projelerinin şaşmasına yol açar: çevirmenler eski stringlerle çalışır, geliştiriciler güncellemeleri çekmeyi unutur ve sürümler yarım yapılmış locale'lerle yayınlanır.

İyi bir uygulama import/export'u tekrarlanabilir bir pipeline olarak ele alır.

Bir import/export pipeline'ı oluşturun

Ekiplerin gerçekten kullandığı yolları destekleyin:

• Repo'dan çekme (GitHub/GitLab/Bitbucket): locale dosyalarını programlı veya isteğe bağlı çekme.
• Repoya itme: güncellenmiş çevirilerle bir PR açma.
• Manuel yüklemeler/indirilmeler: vendor'lar veya legacy projeler için hâlâ gerekli.

Dışa aktarırken filtreleme sunun: proje, branch, locale ve statü (örn. "sadece onaylanmış")—bu, yarı incelenmiş stringlerin üretime sızmasını önler.

String çıkarımı ve kararlı key'ler

Senkronizasyon ancak key'ler stabil kalırsa çalışır. Stringlerin nasıl üretildiğini erken karar verin:

• İnsan tarafından okunabilir key'ler kullanıyorsanız (örn. checkout.button.pay_now) yanlışlıkla yeniden adlandırılmalarını koruyun.
• Hash tabanlı key'ler kullanıyorsanız, güncellemeler gizlice çoğaltmayacak şekilde kaynak metni ve bağlamı saklayın.

Uygulamanız, kaynak string değiştiğinde key aynı kaldıysa çevirileri üzerine yazmak yerine "needs review" olarak işaretlemeli.

Commit ve release için webhook'lar

Senkronizasyon için webhook ekleyin:

• maine yeni commit → güncellenmiş kaynak stringleri import et
• Release tag'i oluşturuldu → onaylı çevirileri export et ve PR aç

Webhook'lar idempotent olmalı ve açık loglar üretmeli: ne değişti, ne atlandı ve neden.

Entegrasyon notu

Uygularken en basit uçtan uca kurulumun (repo erişimi + webhook + PR export) dokümantasyonunu UI'da gösterin.

Lokalizasyon QA Kontrolleri Ekleyin

Lokalizasyon QA, uygulamanızı basit bir editörden üretim hatalarını engelleyen bir sisteme dönüştürür. Amaç, hataları kullanıcıya ulaşmadan önce yakalamaktır.

1) Doğrulama (kritik hatalar)

UI'yi bozabilecek veya formatlamayı çökertabilecek kontrollerle başlayın:

• Eksik veya uyuşmayan yer tutucular (örn. {count} İngilizcede var ama Fransızcada yok)
• Geçersiz HTML (bozuk etiketler)
• Dosya formatı için kaçış hataları (JSON içindeki tırnaklar, printf tarzı stringlerde yanlış %)

Bunları varsayılan olarak sürüm engelleyici yapın ve hatanın hangi key ve locale'de olduğunu açıkça gösterin.

2) Tutarlılık kontrolleri (uyarılar)

Her zaman uygulamayı bozmazlar ama kaliteyi zedelerler:

• Sözlük terimleri: zorunlu bir terim kullanılmadığında veya tutarsız çeviri yapıldığında işaretle
• Noktalama, boşluk ve büyük/küçük harf: çift boşluk, sondaki boşluk, eksik son noktalama vb.

3) Görsel kontroller (bağlam duyarlı)

Metin doğru olabilir ama görünüşü yanlış olabilir. Her key için isteğe bağlı screenshot bağlamı isteyin veya key'e ekran görüntüsü ekleme imkanı verin; böylece çevirmenler daralma, satır kırılması ve ton açısından doğrulama yapabilir.

4) Raporlama (sürüm hazır özeti)

Her sürüm öncesi locale başına QA özeti oluşturun: hatalar, uyarılar, çevrilmemiş stringler ve en çok sorun yaratanlar.

Bunu dışa aktarmayı veya dahili bağlantı paylaşmayı kolaylaştırın ki ekipler tek bir go/no-go görünümüne sahip olsun.

Sözlük, Çeviri Hafızası ve MT Desteği

Sözlük, çeviri hafızası (TM) ve makine çevirisi (MT) lokalizasyon hızını artırabilir—ancak bunlar rehberlik ve otomasyon olarak ele alınmalı, doğrudan yayınlanacak içerik olarak değil.

Sözlük: her locale için onaylı terimler

Sözlük terimler ve her locale için onaylı çevirilerden oluşur (ürün isimleri, yasal ifadeler vb.).

Girdileri terim + locale + onaylı çeviri + notlar + statü olarak saklayın.

Çevirmen çalışma alanında sözlüğü şu şekilde kullanın:

• Kaynak string içinde sözlük eşleşmelerini vurgula ve onaylı hedef terimi öner
• Bir çeviri zorunlu terimden sapıyorsa uyar (veya proje ayarlarına bağlı olarak bloke et)
• Büyük doğruluk için küçük kurallar (ör. küçük/büyük harf duyarsız eşleme) sunun

Çeviri hafızası temel ilkeler

TM geçmişte onaylanmış çevirileri yeniden kullanır:

• İndekslemede normalize edilmiş kaynak metin, bağlam key ve locale kullanın
• Önce onaylanmış segmentleri gösterin; yoksa incelenmiş veya import edilmiş olanlara bakın
• Eşlemenin kalitesini (exact vs fuzzy) ve orijinal bağlamı gösterin

TM bir öneri sistemi olmalı: kullanıcılar kabul edebilir, düzenleyebilir veya reddedebilir; sadece kabul edilen çeviriler TM'ye geri beslenmelidir.

Makine çevirisi (MT) bir yardımcı olarak

MT taslaklar ve backlog için kullanışlıdır ama varsayılan nihai çıktı olmamalıdır.

MT'yi proje ve iş bazında isteğe bağlı yapın ve MT ile doldurulan stringleri normal inceleme sürecinden geçirin.

Maliyet ve gizlilik: admin seçimi

Farklı ekiplerin kısıtlamaları farklıdır. Admin'lerin sağlayıcı seçmesine (veya MT'yi tamamen devre dışı bırakmasına), kullanım limitleri ayarlamasına ve hangi verinin gönderileceğini belirlemesine izin verin.

İstekleri maliyet görünürlüğü ve denetim için loglayın.

Sürümleri Yayınlayın ve Güvenilir Tutun

Bir lokalizasyon uygulaması sadece çevirileri saklamamalı—bunların güvenle dağıtılmasına yardımcı olmalıdır.

Ana fikir bir "sürüm": onaylanmış stringlerin donmuş bir anlık görüntüsü, böylece dağıtılan şey öngörülebilir ve yeniden üretilebilir olur.

Bir sürümün içeriğini tanımlayın

Sürümü değiştirilemez bir paket olarak ele alın:

• Locale + namespace/dosya + key + son onaylı metin
• Metadata: onay durumu, inceleyici, zaman damgaları, kaynak string hash'i
• Opsiyonel: build numarası, git commit ve uygulama versiyonu

Böylece "v2.8.1'de fr-FR için ne yayınladık" sorusuna kesin yanıt verilebilir.

Ortamları destekleyin (staging vs production)

Çoğu ekip çevirileri kullanıcılara gösterilmeden önce doğrulamak ister. Dışa aktarımları ortama göre modelleyin:

• Staging export: yeni onaylanmış stringleri ve isteğe bağlı aday çevirileri önizleme için içerir
• Production export: yalnızca tamamen onaylanmış içeriği içerir ve bir release ID'ye bağlıdır

Dışa aktarma uç noktasını açık hale getirin örn: /api/exports/production?release=123 ki gözden geçirilmemiş metin kazara sızmasın.

Baştan geri alma planlayın

Sürüm immutable olduğunda geri alma en kolay yoldur. Eğer bir sürüm sorun getirirse (kırık yer tutucular, yanlış terminoloji):

• Uygulamayı önceki bir sürüm export'una geri döndürün
• Sorunlu stringleri yeniden açın, düzeltin ve yeni sürüm yayınlayın

Üretimde doğrudan düzenleme yapmaktan kaçının—bu denetim yollarını bozar.

Yayın sonrası kontrol listesi ve izleme

Deploy sonra küçük bir operasyonel kontrol listesi çalıştırın:

• Tüm locale'ler için export başarılı; eksik dosya yok
• Temel runtime duman testleri
• Çeviri hata sinyallerini izleyin (eksik key'ler, yer tutucu uyuşmazlıkları, fallback artışları)

UI'da sürüm geçmişi gösteriyorsanız, önceki sürümle basit bir diff görünümü ekleyin ki ekipler riskli değişiklikleri hızlıca görebilsin.

Güvenlik, Analitik ve Sonraki Adımlar

Güvenlik ve görünürlük, kullanışlı bir araç ile ekiplerin güvenebileceği bir araç arasındaki farktır. İş akışınız çalıştıktan sonra kilitleyin ve ölçmeye başlayın.

Temel güvenlik önlemleri

Varsayılan olarak en az ayrıcalık prensibini uygulayın: çevirmenler proje ayarlarını değiştirmemeli, inceleyiciler fatura veya admin dışa aktarmalarına erişmemeli. Rolleri açık ve denetlenebilir yapın.

Gizli anahtarları güvenli saklayın. Veritabanı kimlik bilgileri, webhook imzalama anahtarları ve üçüncü taraf tokenlarını secrets manager veya şifrelenmiş ortam değişkenlerinde tutun—repoda asla saklamayın. Anahtarları planlı olarak ve birisi ayrıldığında döndürün.

Yedeklemeler zorunludur. Veritabanı ve nesne depolama (locale dosyaları, ekler) için otomatik yedek alın, geri yüklemeyi test edin ve saklama süresini tanımlayın.

Kişisel veriler (PII) dikkate alınması

Stringler kullanıcı içeriği (destek ticket'ları, isimler, adresler) içerebiliyorsa bunları çeviri sisteminde saklamaktan kaçının. Yer tutucular veya referanslar kullanın ve loglardan hassas değerleri temizleyin.

Eğer işlenecekse saklama kuralları ve erişim kısıtlamaları belirleyin.

Gerçekten işe yarayan temel analitik

İş akışı sağlığını yansıtan birkaç metrik takip edin:

• Throughput: gün/hafta başına çevrilen string sayısı
• İnceleme süresi: ortalama "çeviriden onaya" zaman
• En çok değişen key'ler: kararlı olmayan UI alanlarını tespit edin

Basit bir pano ve CSV dışa aktarma başlamak için yeterlidir.

Geliştirme için sonraki adımlar

Temel oturunca şunları düşünün:

• Push/pull ve durum kontrolleri için developer CLI
• UI içinde bağlam önizlemesi sunan in-context editor
• Entegrasyonlar için API anahtarları (CI, GitHub/GitLab, Slack)

Bunu bir ürün olarak sunmayı planlıyorsanız net bir yükseltme yolu ve CTA ekleyin.

Eğer amacınız gerçek kullanıcılarla iş akışını hızlı doğrulamaksa, MVP'yi Koder.ai üzerinde prototipleyebilirsiniz: rolleri, statü akışını ve import/export formatlarını planlayın, React UI ve Go API'yi sohbetle yineleyin ve kod tabanını dışa aktarın.