Güvenli metin güncellemeleri için veritabanı tabanlı yerelleştirme

Neden yerelleştirme güncellemeleri riskli ve yavaş hale gelir

Çoğu ürün hâlâ kullanıcı arayüzü metnini bir sürümün parçası olarak ele alır. Basit bir ifade değişikliği, kodu veya çeviri dosyalarını düzenlemeyi, bir pull request açmayı, inceleme beklemeyi ve yeni bir derlemeyi yayınlamayı gerektirir. Uygulamanızın web ve mobil istemcileri varsa, bu beş dakika sürecek bir değişiklik için birden fazla sürüm anlamına gelebilir.

Metinler kod dosyalarında saklandığında, fark etmeden bir şeyleri kırmak kolaylaşır. Anahtarlar yeniden adlandırılır, dosyalar dallar arasında farklılaşır ve farklı ekipler farklı yerleri günceller. Hiçbir şey kırılmasa bile süreç yavaştır çünkü metni değiştirmek için en güvenli yol genellikle aynı pipeline'ı takip etmektir.

Kullanıcıların bir şeyler ters gittiğinde gördükleri genellikle açıktır:

• checkout.pay_now gibi ham anahtarlar gerçek metin yerine görünür
• Bir ekran içinde dillerin karışması
• Boş etiketler, butonlar veya hata mesajları
• Bölgeye uygun olmayan ifade (para birimi, yasal terimler, destek saatleri)

Çevirilerin eksik olması özellikle can sıkıcıdır çünkü genellikle daha az kullanılan lokallerde ortaya çıkar. İngilizce bir QA kontrolü kusursuz görünebilirken, İspanyolca konuşan bir müşteri en kötü anda çevrilmemiş bir ödeme hatasıyla karşılaşabilir.

Ekipler güncellemelerden kaçınmaya başlar çünkü bunlar riskli hissedilir. Destek daha net bir mesaj ister, hukuk bir feragatname talep eder, pazarlama başlıkta küçük bir değişiklik ister ve herkes bir sonraki sürüm penceresini bekler.

Veritabanı tabanlı yerelleştirme bu modeli değiştirir: çevirileri ve geri dönüş kurallarını güvenle güncellenebilecek, yayınlamadan önce doğrulanabilecek ve anında geri alınabilecek bir yerde saklarsınız. Metin güncellemelerini dağıtım olayı yerine kontrol edilen bir içerik değişikliğine çevirir.

Temel terimler: çeviriler, lokaller, geri dönüşler, varyantlar

Veritabanı tabanlı yerelleştirmeyi planlamak, herkesin aynı terimleri kullandığı zaman daha kolaydır. Bu terimler ayrıca sık değişenleri (pazarlama metni) kalıcı tutulması gerekenlerden (anahtarlar ve kurallar) ayırmanıza yardımcı olur.

Bir çeviri, uygulamanızın gösterdiği dile özgü metindir. İçerik, o metnin arkasındaki anlam ve niyettir. Buton metinleri gibi UI etiketleri için genellikle kısa, tutarlı çeviriler istersiniz ("Kaydet", "İptal"). Onboarding ipuçları, boş durumlar veya yardım metni gibi uzun biçimli içeriklerde, sadece çevirmek değil, doğal gelmesi için yeniden yazmak gerekebilir.

Bir locale hangi versiyonun gösterileceğini belirten dil etiketidir. Sıkça şu örnekleri görürsünüz:

• en (İngilizce)
• en-US (Amerika Birleşik Devletleri'nde kullanılan İngilizce)
• pt-BR (Brezilya'da kullanılan Portekizce)
• fr-CA (Kanada'da kullanılan Fransızca)

Dil kısmı (örneğin en) bölge kısmı (US) ile aynı değildir. İki bölge aynı dili paylaşsa bile farklı kelimeler, para formatları veya yasal ifadeler gerekebilir.

Bir anahtar, uygulamanızın metin istemek için kullandığı kalıcı kimliktir, örneğin checkout.pay_now. Değer ise belirli bir locale için saklanan çevrilmiş metindir. Geri dönüşler, bir değer eksik olduğunda uygulanan kurallardır, böylece UI asla boş veya ham anahtar göstermez. Yaygın bir yaklaşım: önce fr-CA, sonra fr, ardından varsayılan en denenir.

Bir içerik varyantı dil ile ilgili değildir; belirli bir bağlam için farklılıkları ifade eder. Örneğin aynı İngilizce locale, AB ve ABD için veya Ücretsiz ve Pro planları için farklı metinler gerektirebilir. Varyantlar, aynı anahtarı korurken doğru versiyonu kurallarınıza göre güvenle sunmanızı sağlar.

Uzun ömürlü çeviri anahtarları nasıl tasarlanır

Kararlı anahtarlar veritabanı tabanlı yerelleştirmenin temelidir. Anahtar değişirse, her locale girdisi aynı anda "eksik" olur. Amaç basittir: görünür metin değişse bile yıllarca koruyabileceğiniz anahtarlar seçin.

Anahtar verilmeyi hak edenleri belirleyerek başlayın. Kullanıcıya gösterilen ve muhtemelen değişecek her şey anahtar temelli olmalı: buton etiketleri, form ipuçları, boş durumlar, e-posta ve SMS şablonları, push bildirimleri ve yardım metni. Tek seferlik hata ayıklama dizgeleri veya geçici yönetici notları için anahtarlar genellikle fazladan iş yükü getirir.

İnsan tarafından okunabilir anahtarlar, incelemelerde ve destek kayıtlarında yönetmeyi kolaylaştırır, örneğin checkout.button.pay_now. Karma veya otomatik oluşturulan anahtarlar tartışmaları önlese de, geliştirici olmayanların veritabanı arayüzünde doğru dizgeyi bulmasını zorlaştırır. Yaygın bir uzlaşma, açık kurallar ve sahiplikle birlikte insan okunabilir anahtar kullanmaktır.

Ad alanları (namespace) anahtarları düzenli tutar ve kanallar arasında çakışmaları önler. Önce yüzeyi (web, mobile, email), sonra özelliği ayırın. Örnek: web.settings.save, mobile.settings.save, email.invoice.subject. Bu aynı ifadenin kanal bazında farklı olması gerektiğinde de yardımcı olur.

Kararlı tutan birkaç kural:

• Geçerli ifadeyi değil anlamı adlandırın (örneğin button.submit_order, değil button.place_order_now).
• Anahtara iş verisi koymayın (fiyatlar, tarihler, isimler burada yer almaz).
• Anahtarları küçük harf ve tahmin edilebilir tutun, böylece yazması kolay olur.
• Kimlerin anahtar oluşturabileceğine ve çoğaltmaların nasıl ele alınacağına karar verin.

Dinamik değerler için birleştirilmiş parçalar yerine yer tutucular içeren bir şablon saklayın. Örnek: "Hi {first_name}, your plan renews on {date}." Uygulamanız first_name ve locale formatlı date değerini sağlar. AppMaster ile geliştiriyorsanız, aynı içeriğin web, mobil ve e-postalarda dokunulmadan güncellenebilmesi için yer tutucuları tutarlı tutun.

Çevirileri saklamak için pratik bir veritabanı modeli

İşlevsel bir veritabanı tabanlı yerelleştirme modeli bilerek basittir. Çalışma zamanında sorgulanması kolay, ancak insanları düzenlerken UI'yi bozmayacak bir yapı istersiniz.

Başlangıç olarak iki kavram: kararlı bir çeviri anahtarı (ör. billing.plan.pro.title) ve locale başına bir değer. PostgreSQL (AppMaster’ın Data Designer'ı ile iyi uyumlu) kullanıyorsanız genellikle bir anahtar tablosu ve bir çeviri tablosu yeterlidir.

-- Translation keys (stable identifiers)
create table i18n_key (
  id bigserial primary key,
  key text not null unique,
  description text
);

-- Actual translated values
create table i18n_translation (
  id bigserial primary key,
  key_id bigint not null references i18n_key(id),
  locale text not null,          -- e.g. en-US, fr-FR
  value text not null,
  status text not null,          -- draft, review, published
  source text,                   -- manual, import, vendor
  updated_by text,
  updated_at timestamptz not null default now(),
  is_published boolean not null default false,
  unique (key_id, locale)
);

Meta veriler süs değildir. updated_by ve updated_at size sorumluluk sağlar; source daha sonra neden metnin değiştiğini denetlemek istediğinizde yardımcı olur.

Versiyonlama için iki yaygın seçenek vardır. En basiti yayın bayrağıdır: editörler taslak kaydeder, onaylandığında is_published'ı (veya statusu) değiştirirler. Tam bir geçmişe ihtiyacınız varsa, eski değerleri revizyon numarası ve değiştireniyle saklayan bir i18n_translation_revision tablosu ekleyin.

Uzun metinler için net bir kural belirleyin. text kullanın (kısa varchar değil) ve hangi biçimlendirmeye izin vereceğinize karar verin: sadece düz metin mi, yoksa güvenli şekilde render edeceğiniz sınırlı bir işaretleme mi. {name} veya {count} gibi yer tutucular destekliyorsanız, kaydetme sırasında bunları doğrulayın ki uzun bir paragraf zorunlu bir token'ı kazara silmesin.

İyi yapıldığında, bu model ekiplerin metni güvenle güncellemesine ve çalışma zamanında aramaların öngörülebilir kalmasına izin verir.

Kırık UI metinlerini önleyen geri dönüş kuralları

İyi bir geri dönüş sistemi, bir çeviri eksik olsa bile UI'nizin okunabilir kalmasını sağlar. Veritabanı tabanlı yerelleştirmede bu çoğunlukla politika meselesidir: sıralamayı bir kez kararlaştırın ve her ekranın buna uymasını sağlayın.

İnsanların dilin nasıl çalıştığını beklediği zincire göre başlayın. Yaygın bir desen:

• Önce tam locale'yi deneyin (örnek: fr-CA)
• Eksikse baz dili deneyin (fr)
• Hâlâ yoksa varsayılan locale'i kullanın (genellikle en)
• Son çare olarak güvenli bir yer tutucu gösterin

Son adım önemlidir. Bir anahtar her yerde eksikse boş bir etiket göstermeyin. Boş bir buton akışı bozabilir çünkü kullanıcı neye tıkladığını bilmez. Test sırasında sorunları görünür kılacak, üretimde de kullanışlı kalacak bir yer tutucu kullanın; örneğin köşeli parantez içinde anahtar adı ([checkout.pay_now]).

Baz dili mi yoksa yer tutucuyu mu göstermelisiniz? Baz dil için bir değer varsa onu gösterin. Özellikle Kaydet, İptal veya Ara gibi yaygın UI eylemleri için bu genellikle yer tutucudan daha iyidir. Yer tutucuları, gerçekten hiçbir yerde bulunmayan durumlar veya varsayılan dili göstermenizin yasal/marka açısından sorun yaratacağı özel durumlar için saklayın.

Eksik anahtarlar loglanmalıdır, ancak loglama sınırlandırılmalıdır ki gürültüye dönüşmesin.

• Her istekte değil, anahtar başına bir kez uygulama sürümü (veya günlük) bazında loglayın
• Eyleme dönüştürülebilecek bağlam (ekran, locale, anahtar) dahil edin
• Locale bazında eksik anahtar metriği tutun
• Yönetim araçlarında loglara güvenmek yerine "fr-CA'de eksik" raporu gösterin

Örnek: uygulamanız bir Kanada kullanıcısı için fr-CA ister. Pazarlama sadece fr metnini güncellediğinde kullanıcılar kırık UI yerine Fransızca görür ve ekibiniz fr-CA'nın dikkat gerektirdiğine dair tek ve net bir sinyal alır.

Bölge, plan ve diğer farklılıklar için içerik varyantları

Çeviriler her zaman tam hikaye değildir. Bazen aynı dil, kullanıcının nerede olduğuna, ne ödediğine veya nasıl geldiğine bağlı olarak farklı metinler gerektirir. İşte içerik varyantları burada devreye girer: bir temel mesaj tutulur, ardından belirli durumlar için küçük üst yazmalar saklanır.

Aşırı karmaşıklaştırmadan destekleyebileceğiniz yaygın varyant türleri:

• Bölge (US vs UK yazımı, yasal ifadeler, yerel destek saatleri)
• Plan (Free vs Pro özellik adları, upsell metni)
• Kanal (web vs mobile, e-posta vs uygulama içi ifade)
• Hedef kitle (yeni kullanıcı vs dönen kullanıcı)
• Deney (A/B testi metni)

Anahtar, varyantları küçük tutmaktır. Değişen sadece şeyi saklayın, tüm dizgilerin tam bir kopyasını değil. Örneğin, temel CTA "Start free trial" kalsın; sadece birkaç ekranda Ücretsiz kullanıcılar için "Upgrade to Pro" gerekiyorsa onu override edin.

Birden fazla varyant eşleşebiliyorsa (örneğin, Kanada'da Pro kullanıcı ve mobilde) UI'nın öngörülebilir kalması için açık öncelik kurallarına ihtiyacınız vardır. Basit bir yaklaşım "en özel kazansın" şeklindedir; hangi kaç niteliğin eşleştiğine göre değerlendirin.

Birçok ekip tarafından kullanılan pratik öncelik sırası:

• Locale + tüm varyant özniteliklerinde tam eşleşme
• Locale + en önemli öznitelikte eşleşme (çoğunlukla plan)
• Sadece locale ile eşleşme (temel çeviri)
• Locale geri dönüşü (ör. fr-CA → fr)

Her küçük değişiklik için varyant oluşturmamak adına bir eşik belirleyin: fark kullanıcı eylemi, uyumluluk veya anlam açısından önemli olduğunda varyant ekleyin. Kozmetik tercihler (iki sıfatın yer değiştirmesi gibi) yazım rehberleriyle halledilmeli, ekstra dallarla değil.

AppMaster'da kurarsanız, varyantları çeviri tablosunda isteğe bağlı alanlar olarak modelleyebilir ve onaylı override'ları geliştirici müdahalesi olmadan tek bir yerden düzenlemeye izin verebilirsiniz.

Geliştirici olmayanlar için güvenli bir düzenleme iş akışı

Metin veritabanında saklanırsa, geliştirici olmayanlar metni beklemeden güncelleyebilir. Bu ancak çevirileri bir içerik gibi ele alırsanız çalışır: net roller, onaylar ve hatayı geri almanın kolay bir yolu olmalı.

Sorumlulukları ayırarak başlayın. Bir yazar ifade değiştirebilmeli ama tek başına yayınlayamamalı. Çevirmenler aynı kararlı anahtarlardan çalışmalı. İnceleyiciler anlam ve tonu kontrol etmeli. Yayıncı son kararı verip değişiklikleri canlıya almalı.

İyi işleyen basit bir iş akışı:

• Yazar bir veya daha fazla locale için metni Taslak (Draft) halinde oluşturur veya düzenler.
• Çevirmen eksik lokalleri aynı anahtar ve notlarla ekler.
• İnceleyici girdiyi onaylar (veya yorumla geri gönderir).
• Yayıncı Taslak'ı seçilen ortama (staging veya production) taşır.
• Sistem kim neyi ne zaman değiştirdiğini kaydeder.

Bu son adım önemlidir. Her değişiklik için anahtar, locale, eski değer, yeni değer, yazar, zaman damgası ve isteğe bağlı bir gerekçe içeren bir denetim izi tutun. Basit bir log bile hızlı hareket etmeyi güvenli kılar çünkü ne olduğunu tam olarak görebilirsiniz.

Geri alma (rollback) birinci sınıf aksiyon olmalı, manuel temizleme değil. Bir başlık UI'yi bozarsa veya çeviri yanlışsa, önceki Yayınlanmış versiyona tek tıkla dönmek istemelisiniz.

Hızlı bir geri alma planı:

• Anahtar ve locale başına versiyon geçmişi tutun.
• "Önceki yayımlanana geri dön" seçeneği sunun (sadece taslağı geri almaktan daha fazlası).
• Geri almaları izinlere bağlayın (sadece yayıncı).
• Onaylamadan önce etkilenecek ekranları veya etiketleri gösterin.

AppMaster gibi bir no-code araçta bunu modelleyebilir, durumları, izinleri ve logları görsel olarak kurabilir ve yine de ekiplerin beklentisi olan güvenlik ağını sağlayabilirsiniz.

Adım adım: veritabanı tabanlı yerelleştirmeyi uygulama

Öncelikle bugün gösterdiğiniz tüm kullanıcıya dönük dizgeleri listeleyin: butonlar, hata mesajları, e-postalar ve boş durumlar. Sahipliği net tutmak ve değişiklikleri daha hızlı gözden geçirmek için bunları ürün alanına göre gruplayın (checkout, profil, destek).

Sonra kararlı çeviri anahtarlarını tanımlayın ve her zaman bir değeri olacak bir varsayılan dil seçin. Anahtarlar niyeti tanımlamalı, ifadeyi değil (örneğin checkout.pay_button). Böylece kopya değişse bile referanslar kırılmaz.

Veritabanı tabanlı yerelleştirmenin basit bir uygulama yolu:

• Dizgeleri alan bazında toplayın ve her alan için kimlerin değişikliği onaylayacağını belirleyin.
• Anahtarları oluşturun, bir varsayılan locale belirleyin ve çoğul ile değişken değerleri nasıl ele alacağınızı kararlaştırın.
• status (draft, published), updated_by ve published_at gibi alanlara sahip çeviri tabloları oluşturun.
• İstenen locale, sonra geri dönüş locale'leri, sonra varsayılanı kontrol eden bir lookup katmanı ekleyin. Sonucu önbelleğe alın ki fazladan DB okuması olmasın.
• Geliştirici olmayanların düzenleyip önizleyip yayınlayabileceği bir yönetici ekranı oluşturun.

Son olarak önlemler ekleyin. Eksik anahtarları, geçersiz yer tutucuları (ör. eksik {name}) ve biçimlendirme hatalarını loglayın. Bu loglar locale ve uygulama sürümüne göre filtrelenebilir olmalı.

AppMaster kullanıyorsanız, Data Designer'da tabloları modelleyebilir, UI builder ile düzenleme ve yayın ekranlarını oluşturabilir ve Business Process ile onay kurallarını zorunlu kılabilirsiniz. Bu, ekiplerin hızlı hareket etmesini sağlarken güvenliği korur.

Örnek senaryo: redeploy etmeden kopya güncelleme

Bir müşteri portalı İngilizce (en), İspanyolca (es) ve Kanada Fransızcası (fr-CA) desteklesin. UI metni uygulama derlemesine gömülü değil; çalışma zamanında bir çeviri tablosundan yükleniyor.

Cuma öğleden sonra pazarlama, fiyatlandırma bandını "Start free, upgrade anytime"'den "Try free for 14 days, cancel anytime"'a değiştirmek istiyor. Ayrıca mobil için daha kısa bir versiyona ihtiyaç var.

Mühendislerden sürüm kesmelerini istemek yerine, bir içerik editörü dahili "Translations" ekranını açar, portal.pricing.banner anahtarını arar ve en değerini günceller. Ekran boyutuna göre doğru kopyayı seçmesi için mobil varyantı olarak ikinci bir değer ekler.

İspanyolca da güncellenir, ama fr-CA hâlâ eksik kalır. Bu sorun değil: portal otomatik olarak fr-CA'dan fr'ye geri döner, böylece Fransızca kullanıcılar boş bir etiket veya ham anahtar yerine okunabilir bir mesaj görür.

Bir inceleyici İngilizce metinde bir yazım hatası fark eder. Her düzenleme versiyonlanmış olduğundan, önceki değere dakikalar içinde geri dönebilirler. Backend yeniden dağıtımı gerekmez, iOS veya Android için app store güncellemesi yoktur.

Pratikte şu olur:

• Pazarlama en ve es değerlerini düzenler ve kaydeder.
• Sistem eski değerleri önceki bir versiyon olarak saklar.
• Kullanıcılar değişikliği bir sonraki yenilemede (veya önbellek süresi dolduğunda) görür.
• fr-CA kullanıcıları fr geri dönüşünü görür, ta ki fr-CA eklenene kadar.
• Bir inceleyici yazım hatasını tek bir işlemle geri alır.

AppMaster'da aynı fikir küçük bir yönetici paneli, rol bazlı erişim (editör vs inceleyici) ve canlıya almadan önce basit bir onay adımı ile desteklenebilir.

Test, izleme ve performansı sabit tutma

Metin veritabanından değişebildiğinde kalite kontrolleri hızlı ve tekrarlanabilir olmalı. Amaç basit: her locale doğru görünmeli, anlamlı okunmalı ve güncellemeden hemen sonra bile hızlı yüklenmelidir. Bu, veritabanı tabanlı yerelleştirmenin vaadi; doğru öğeleri izlerseniz işler.

Her düzenleme paketinden sonra küçük bir duman testi ile başlayın. En çok görülen sayfaları (giriş, gösterge paneli, ödeme, ayarlar) seçin ve bunları desteklenen her locale'de görüntüleyin. Hem masaüstünde hem de küçük bir telefon ekranında yapın; en yaygın hata uzun çevirilerin mobilde sığmamasıdır.

En çok sorun yakalayan hızlı kontroller:

• Kesilmiş butonlar, sarılmış başlıklar ve bozulan menüler için tarama (mobilde uzun çeviriler en sık sebep)
• Yer tutucusu olan mesajları deneyin ve formatın sağlam olduğunu doğrulayın, örn. {name}, {count}, {date}
• Hata durumlarını ve boş durumları tetikleyin (bunlar genellikle unutulur)
• Oturum ortasında locale değiştirin ve UI'nın eski dizgilerle kalmadan yenilendiğini doğrulayın
• En çok kullanılan akışlarda açık fallback metni (anahtar adı veya varsayılan dil) arayın

İzleme size sistemin zamanla kötüye gidip gitmediğini söylemelidir. Eksik anahtarlar per locale, fallback sayıları ve düzenlemeler sonrası geri alma sayıları gibi sayıları takip edin. Ani bir yükseliş genellikle bir anahtarın değiştiğini, yer tutucu uyuşmazlığı veya kötü bir iyi aktarma olduğunu gösterir.

Performans için güvenli olanı önbelleğe alın: çözülmüş çeviriler per locale ve versiyon, kısa bir yenileme aralığı veya basit bir "çeviri versiyonu" numarası ile. AppMaster gibi araçlarda bu, yayına alma sırasında hafif bir yenileme ile eşleştirilebilir; böylece kullanıcılar hızlı alır ve her sayfa görüntülemede ekstra yük oluşmaz.

Yaygın hatalar ve nasıl kaçınılır

Veritabanı tabanlı yerelleştirme metin değişikliklerini hızlandırır, ama birkaç yaygın yanlış adım sisteminizi kırık ekranlar ve kafa karıştırıcı metinlerle doldurabilir.

Biri üretim metnini herhangi bir inceleme olmadan düzenleyebiliyorsa bu bir risktir. Metin değişiklikleri yalnızca izlenebiliyorsa "güvenli"dir: ne değiştiğini, kim değiştirdiğini ve ne zaman yayımlandığını görebilmelisiniz. Metni kod gibi ele alın: taslaklar, onaylar ve net bir yayın adımı kullanın. Basit bir kural işe yarar: düzenlemeler önce staging'de yapılır, sonra tanıtılır.

Kararsız anahtarlar uzun vadede acı verir. Anahtar şu anki cümleye dayanıyorsa ("welcome_to_acme" sonra "welcome_back" oluyorsa) her yeniden yazım yeniden kullanım ve analizleri bozar. "home.hero.title" veya "checkout.cta.primary" gibi amaç temelli, kararlı anahtarları tercih edin ve ifadeler değişse bile anahtarları koruyun.

Farklı yerlerde gömülü geri dönüş kuralları bir başka tuzaktır. Backend İngilizce'ye geri dönerken mobil uygulama "herhangi bir mevcut olan" a geri dönüyorsa, kullanıcılar platformlar arasında farklı metinler görür. Geri dönüş kurallarını tek bir yerde (genellikle backend servis) tutun ve her istemcinin ona uymasını sağlayın.

Zengin metin için kurallar olmalı. Çevirmenler veritabanına HTML yapıştırabiliyorsa, kötü bir etiket düzeni düzeni bozabilir veya güvenlik sorunlarına yol açabilir. Yer tutucular kullanın ({name}) ve yayınlamadan önce sınırlı bir biçimlendirme setini doğrulayın.

Son olarak, varyantlar patlayabilir. Bölge, plan ve A/B testi varyantları faydalıdır, ama çok fazla olduğunda izlenemez hale gelir.

Çoğu ekip için işe yarayan düzeltmeler:

• Üretim dizgeleri için inceleme ve zamanlanmış yayınlama zorunlu kılın
• Anahtarları kararlı tutun ve gerçek metinden ayırın
• Geri dönüşleri merkezileştirin ve geri dönüş kullanıldığında loglayın
• Yer tutucuları doğrulayın ve biçimlendirmeyi kısıtlayın
• Varyantlara limit koyun ve kullanılmayanları düzenli silin

Örnek: bir pazarlama yazarı bir "Pro" plan varyantı için CTA'yı günceller ama "Default" varyantını güncellemeyi unutur. Gereken varyantlar eksik olduğunda yayınlamayı engelleyen bir doğrulama kuralı ile boş buton etiketinden kaçınırsınız. AppMaster'da aynı fikir uygulanır: çeviri veri modelini katı tutun, yayınlamadan önce doğrulayın ve metni korkmadan güncelleyin.

Hızlı kontrol listesi ve sonraki adımlar

Veritabanı tabanlı bir yerelleştirme kurulumu ancak kurallar net ve düzenleme akışı korumalarla çevrili olduğunda "güvenli" olur. Geliştirici olmayanları metin güncellemesi yapmaya davet etmeden önce, genellikle kırık UI metnine yol açan boşlukları tespit etmek için bu kısa kontrol listesini kullanın.

Hızlı kontrol listesi

• Varsayılan locale açıkça belirlenmiş ve her locale için geri dönüş zinciri tanımlanmış (örn: fr-CA -> fr -> en)
• Çeviri anahtarları kararlı, insan okunur ve ürün alanına göre gruplanmış (örn: auth., billing., settings.*)
• Yayınlama ve geri alma mühendislik yardımı olmadan mümkün (taslak -> inceleme -> yayın, artı tek tıkla geri al)
• Eksik anahtarlar ve yer tutucu hataları loglanıyor (hangi ekran, hangi locale ve ham şablon dahil)
• Performans korunuyor (yayımlanmış dizgileri önbelleğe alın, her etiket için istek başına DB sorgusundan kaçının)

Sonraki adımlar

Küçük başlayın: bir ürün alanı seçin (onboarding veya faturalama gibi) ve yalnızca o metni veritabanına taşıyın. Bu, tüm uygulamayı riske atmadan gerçek bir test sağlar.

Veri modelini ve basit bir editör UI prototipini AppMaster'da kurun. Editörü odaklı tutun: anahtara göre arama, locale başına düzenleme, değişkenlerle önizleme ve çeviri eksik olduğunda hangi fallback'in kullanılacağını gösterme.

Sonra yerelleştirme servisini web ve mobil uygulamalarınıza bağlayın. İlk entegrasyonu salt-okunur yapın, böylece anahtar kapsaması, geri dönüşler ve önbellekleme davranışını doğrulayabilirsiniz. Ardından onaylar ve geri alma düğmesi ile yayınlamayı etkinleştirin.

Son olarak, yerelleştirme güncellemelerini diğer üretim değişiklikleri gibi ele alın: değişiklikleri inceleyin, ana kullanıcı akışlarında hızlı bir duman testi çalıştırın ve yayımladıktan sonraki ilk gün için "eksik anahtar" loglarını izleyin. Bu, kullanıcılar bulmadan önce boşlukları yakalamanın en hızlı yoludur.