Çeviri iş akışlarını, yerel verileri, incelemeleri, kalite kontrollerini ve yayınları yöneten bir web uygulaması planlayın. Veri modeli, kullanıcı deneyimi ve entegrasyonları içerir.
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.
Çoğu ekip iyi niyetle başlar ama sonunda karmakarışık olur:
Yararlı bir lokalizasyon yönetim web uygulaması birden fazla rolü desteklemelidir:
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.
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.
Çeviriler nadiren tek yerde yaşar. İlk günden itibaren desteklemeniz gerekenleri yazın:
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.
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.
Bir kaynak dil (çoğunlukla en) tanımlayın ve fallback davranışını belirleyin:
ene geri dönerpt-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 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.
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.
Çoğu ekip küçük bir tablo seti ile ihtiyaçlarının %80'ini karşılayabilir:
en, en-GB, pt-BR).checkout.pay_button).İ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.
Her çeviriye bir durum ekleyin ki sistem insanlara rehberlik edebilsin:
draft → in_review → approvedblockedDurum değişikliklerini olay (event) veya bir geçmiş tablosu olarak tutun ki "kim bunu ne zaman onayladı" sorusuna cevap verebilesiniz.
Çeviriler yalnızca düz metin değildir. Şunları yakalayın:
{name}, %d) ve bunların kaynağa uyma gerekliliğiEn 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 kararları düzenleme UX'ini, import/export hızını, diff alma ve güvenle yayınlama yeteneğini etkiler.
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ı.
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ü 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.
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.
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.
Ortak ve ölçeklenebilir bir kurulum: API + web UI + arka plan işleri + veritabanı:
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'yi birkaç ana kaynak etrafında tutun:
checkout.button.pay).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".
Otomasyonu asenkron olarak ele alın. Kuyruk tipik olarak şunları işler:
İşleri idempotent yapın ve proje başına iş logları kaydedin ki ekipler hataları kolayca teşhis edebilsin.
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.
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.
Basit bir rol seti çoğu ekip için yeterlidir:
Her eylemi bir izin olarak ele alın ki ileride kolayca evrilebilsin. Yaygın kurallar:
Bu, çeviri yönetim sistemini esnek ama güvenli tutar.
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.
Kısa ömürlü, güvenli oturumlar (HTTP-only cookie), CSRF koruması, rate limit ve mümkünse 2FA kullanın.
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.
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.
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".
İ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.
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.
Yoğun çevirmenler editörde saatler geçirir. Tam klavye navigasyonu, görünür odak durumları ve şu kısayollar olsun:
Ekran okuyucular ve yüksek kontrast modu desteği ekleyin—erişilebilirlik herkesin hızını artırır.
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.
İş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.
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.
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.
İ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.
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.
Ekiplerin gerçekten kullandığı yolları destekleyin:
Dışa aktarırken filtreleme sunun: proje, branch, locale ve statü (örn. "sadece onaylanmış")—bu, yarı incelenmiş stringlerin üretime sızmasını önler.
Senkronizasyon ancak key'ler stabil kalırsa çalışır. Stringlerin nasıl üretildiğini erken karar verin:
checkout.button.pay_now) yanlışlıkla yeniden adlandırılmalarını koruyun.Uygulamanız, kaynak string değiştiğinde key aynı kaldıysa çevirileri üzerine yazmak yerine "needs review" olarak işaretlemeli.
Senkronizasyon için webhook ekleyin:
maine yeni commit → güncellenmiş kaynak stringleri import etWebhook'lar idempotent olmalı ve açık loglar üretmeli: ne değişti, ne atlandı ve neden.
Uygularken en basit uçtan uca kurulumun (repo erişimi + webhook + PR export) dokümantasyonunu UI'da gösterin.
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.
UI'yi bozabilecek veya formatlamayı çökertabilecek kontrollerle başlayın:
{count} İngilizcede var ama Fransızcada yok)%)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.
Her zaman uygulamayı bozmazlar ama kaliteyi zedelerler:
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.
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ı (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 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:
TM geçmişte onaylanmış çevirileri yeniden kullanır:
TM bir öneri sistemi olmalı: kullanıcılar kabul edebilir, düzenleyebilir veya reddedebilir; sadece kabul edilen çeviriler TM'ye geri beslenmelidir.
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.
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.
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.
Sürümü değiştirilemez bir paket olarak ele alın:
Böylece "v2.8.1'de fr-FR için ne yayınladık" sorusuna kesin yanıt verilebilir.
Çoğu ekip çevirileri kullanıcılara gösterilmeden önce doğrulamak ister. Dışa aktarımları ortama göre modelleyin:
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.
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):
Üretimde doğrudan düzenleme yapmaktan kaçının—bu denetim yollarını bozar.
Deploy sonra küçük bir operasyonel kontrol listesi çalıştırın:
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 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.
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.
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.
İş akışı sağlığını yansıtan birkaç metrik takip edin:
Basit bir pano ve CSV dışa aktarma başlamak için yeterlidir.
Temel oturunca şunları düşünün:
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.
Lokalizasyon yönetim web uygulaması, stringlerinizi merkezileştirir ve etraflarındaki iş akışını yönetir: çeviri, inceleme, onay ve dışa aktarma. Böylece ekipler kırık anahtarlar, eksik yer tutucular veya belirsiz durumlar olmadan güncellemeleri yayınlayabilir.
Kapsam belirlerken şunları netleştirin:
pt-BR → pt → en)Sıkı bir kapsam, "her iş akışına uyan tek çözüm" hatasını önler ve MVP'yi kullanılabilir kılar.
Çoğu ekip için temel veri modeli şunları kapsar:
Üretim hatalarını ve tekrar eden inceleme sorunlarını önlemek için şu meta verileri saklayın:
Hangi amaca öncelik verdiğinize bağlıdır:
Genellikle hibrit bir yaklaşım kullanılır: row-per-key ana gerçek kaynak olarak saklanır ve dışa aktarma için üretilmiş dosya snapshot'ları tutulur.
İki katman önerilir:
Bu yöntem, yayınlanmış içeriklerin sonradan sessizce değişmesini engeller ve olay çözümlemeyi kolaylaştırır.
İşleyen bir izin modeli için temel roller:
API'yi birkaç ana kaynak etrafında tutun:
Projects, Locales, Keys, TranslationsArdından liste uç noktalarını gerçek işleri destekleyecek şekilde filtrelenebilir yapın, örn:
Erken planlanması gereken arka plan işleri:
İşleri idempotent yapın (yeniden denenebilir) ve proje başına job logları tutun ki ekipler hata sebebini sunucu loglarına bakmadan görebilsin.
Yayın engelleyici kontroller önceliklendirilmelidir:
{count}, %d) ve çoğul form kapsamıBunlar varsayılan olarak release-blocking yapılmalı; sözlük tutarlılığı ve boşluk/kas kullanımına dair uyarılar daha yumuşak olabilir.
draft → in_review → approved)Bu varlıklar temiz olduğunda UI ekranları, izinler ve entegrasyonlar oluşturmak çok daha kolay olur.
created_by, updated_by, zaman damgaları, değişiklik nedeni)Bu bilgiler, basit bir metin editöründen güvenilir bir sisteme geçişi sağlar.
Ayrıca eylem temelinde izinler tanımlayın (kaynağı düzenleme, onaylama, dışa aktarma, yerel ekleme) ki sistem evrildikçe kırılmasın.
Böylece hem UI hem de otomasyon (CLI/CI) için uygun olur.