E-posta yerelleştirmesi: Başlıca tüm ESP'lerde kampanyalar nasıl çevrilir
Her e-posta platformunun dile yaklaşımı farklıdır. Bazıları çeviriyi sizin yerinize halleder, bazıları önünüze boş yerel ayar alanları koyar, biri ise sizi koşullu ifadeleri elle yazmakla baş başa bırakır. İşte Braze, Customer.io, Klaviyo, Mailchimp, Iterable ve Brevo'nun gerçekte neler sunduğu ve Liquid yapılarını bozmadan metni nasıl çevirebileceğiniz.

Bu sayfada
Yaşam döngüsü pazarlaması yönetiyorum, bu yüzden ömrümün hatırı sayılır bir kısmını kampanya editörlerinde geçirdim; e-posta yerelleştirmesi ise hep hafife aldığım bir konuydu. Bir açılış sayfasını çevirmek tek tip bir iştir. E-posta kampanyası çevirmek ise dokunduğunuz her araçta bambaşka bir işe dönüşür; çünkü her platform "dilin" ne olduğuna bile birbirinden bağımsız şekilde karar vermiştir.
Bazı platformlar metni sizin yerinize çevirir. Bazıları size boş yerel ayar alanları verir ve bunları doldurmanızı bekler. Bir tanesi ise e-posta gövdesinin içine dallanma mantığı yazmanızı ister. Ancak hepsinin temelinde aynı risk yatar: Metniniz, çeviriden karakteri karakterine dokunulmadan dönmesi gereken şablon sözdizimleriyle doludur; aksi takdirde gönderim bozulur.
Bu kılavuz, başlıca platformların her birinin gerçekte neler yaptığını, metni nasıl dışarı aktarıp geri yükleyeceğinizi ve işin her yerde aynı olan kısımlarını ele alıyor.
E-posta platformlarının dili ele almasının üç yolu
Platform bazlı detaylara girmeden önce, bu üç mimariden hangisiyle karşı karşıya olduğunuzu bilmekte fayda var. Tüm iş akışınızı bu yapı şekillendirir ve genellikle bunu değiştirme şansınız olmaz.
| Mimari | Platformun sundukları | Sizin sağladıklarınız | Platformlar |
|---|---|---|---|
| Çeviriyi sizin yerinize yapar | Editör içinde makine çevirisi, varsayılan dilden üretilen dile özel varyantlar | İnceleme, düzeltmeler, çevrilmeyecekler listesi | Klaviyo, Customer.io, Brevo |
| Size yerel ayar alanları sunar | Etiketlenmiş içerik, varyant iskeleti, CSV veya API ile gidiş-dönüş veri aktarımı | Çevirilerin kendisi | Braze, Iterable |
| Size hiçbir şey sunmaz | Birleştirme etiketleri ve koşullu ifadeler | E-posta gövdesine dallanma mantığı olarak yazılan her şey | Mailchimp |
Ciddi çok dilli programların çoğu orta satırda yer alır ve bu kılavuzun en çok üzerinde durduğu kısım da burasıdır; çünkü "platformun size boş bir yerel ayar tablosu sunması", bir çeviri iş akışına tam olarak ihtiyaç duyulan andır.
Braze e-posta yerelleştirmesi
Braze, "etiketle ve doldur" modelini kullanır ve bu modeller arasında en kendine has sözdizimine sahiptir. E-postadaki her bir çevrilebilir parçayı, bir ID içeren Liquid etiketiyle sarmalarsınız:
{% translation greeting %}Hello!{% endtranslation %}Genel yapı {% translation id_buraya %}varsayılan metin{% endtranslation %} şeklindedir ve ID'lerin bir mesaj içinde benzersiz olması gerekir. Seçili bir alanı sarmalamak için bir editör kısayolu mevcuttur (macOS'ta Cmd+Alt+L, Windows'ta Ctrl+Alt+L). Braze kendi başına herhangi bir çeviri yapmaz: Çevirileri bir CSV dosyası yükleyerek veya bu yazının yazıldığı sırada erken erişim aşamasında olan çeviri API'si aracılığıyla siz sağlarsınız.
Kampanya ciddiye bindiğinde, dokümante edilen limitler önem kazanır:
| Limit | Değer |
|---|---|
| Mesaj başına çeviri etiketi | 200 |
| Varsayılan metin başına karakter | 2.000 |
| Yerel ayar başına çeviri | 409.600 bayt (yaklaşık 409,6 KB) |
| Çalışma alanı başına yerel ayar | 200 |
İç içe geçmiş çeviri etiketleri desteklenmez. Yerel ayar; Ayarlar → Yerelleştirme Ayarları altından yapılandırılan kullanıcı profilinden, varsayılan language ve country öznitelikleri veya özel bir öznitelik aracılığıyla gelir; her ikisinin de tanımlı olduğu durumlarda özel öznitelik öncelik kazanır.
Başlamadan önce Braze'e özgü iki detayı bilmenizde fayda var:
Bir URL'yi sarmalamak, sarmalanan kısım ? veya & ile bitmediği sürece tıklama takibini bozar. Braze, bu durum için geçici çözümü doğrudan belgeliyor:
<a href="https://{% translation id_1 %}example.com{% endtranslation %}?">Shop Now</a>Çeviri CSV dosyasını Excel'de açmayın. Braze'in kendi belgeleri, İngilizce dışındaki karakterlerde yaşanan görüntüleme sorunları nedeniyle bundan kaçınılması gerektiğini belirtiyor. Bu, bir Braze yerelleştirme sürecinin kimse fark etmeden bozulmasının en yaygın yoludur ve bunun nedeni Braze değil Excel'dir: Excel, CSV kodlamasını tahmin etmeye çalışır ve yanlış tahmin eder.
Braze'in İçerik Blokları kendi çevirilerini içerebilir; bu sayede ortak bir alt bilgiyi her kampanya için ayrı ayrı değil, tek bir seferde yerelleştirebilirsiniz. Bunlara {{content_blocks.${your_block}}} şeklinde atıfta bulunulur; Liquid aracılığıyla eklenen bloklar bağlı kalır ve otomatik olarak güncellenir, ancak editörün açılır menüsünden eklenenler güncellenmez. Bir bloğun belirli bir yerel ayar için çevirisi yoksa hata vermek yerine orijinal dilinde görüntülenir.
Etiketleme yapmak yerine dallara ayırmayı tercih ederseniz, Braze manuel yöntemi de destekliyor:
{% if ${language} == 'en' %}
English content
{% elsif ${language} == 'es' %}
Spanish content
{% else %}
Fallback content
{% endif %}Liquid etiketi içinde özniteliğin yalın ${language} şeklinde kullanıldığını, gövde metninde ise {{${language}}} olarak sarmalandığını unutmayın. Bazı kullanıcıların dil ayarı yapılmamış olabileceği, desteklenmeyen bir dil kullanabileceği veya cihazlarındaki dilin tespit edilemeyebileceği durumlar için Braze, her zaman {% else %} dalını eklemenizi önerir.
Belgeler: Braze yerelleştirmesi
Customer.io e-posta yerelleştirmesi
Customer.io tam tersi bir yaklaşım benimsedi: Yerelleştirme özelliği yerleşik olarak sunulur, doğrudan mesaj düzenleyicinin içinde yer alır ve yapay zeka destekli bir otomatik çeviri düğmesi içerir. Mesajı varsayılan bir dilde oluşturup kampanyanızı dallara ayırmanıza gerek kalmadan dil varyantları ekleyebilirsiniz. Bu özellik e-posta, SMS, WhatsApp, anlık bildirim ve uygulama içi mesajların tamamında çalışır.
Dil özniteliğinin ismini siz belirlersiniz. Çalışma Alanı Ayarları → Dil ayarları kısmından Customer.io'ya hangi profil özniteliğinin dil bilgisini barındırdığını belirtirsiniz; bu language, locale veya CRM'inizin halihazırda kullandığı herhangi bir ifade olabilir. Değerler ya iki harfli bir kod (en) ya da tire ile ayrılmış bir dil-bölge çifti (en-US) olmalıdır. Değerler büyük-küçük harfe duyarlı değildir, dolayısıyla es-MX ve es-mx seçeneklerinin ikisi de geçerlidir ancak tire kullanımı zorunludur.
Otomatik çeviri gövde metnini, konu satırlarını ve ön başlık metnini kapsar. Kapsamadığı ve aklınızın bir köşesine yazmanız gereken liste ise şudur:
- Görseller (alt metinleri çevirse de)
- Zengin metin ve kod düzenleyicilerindeki e-posta düzenleri
- Liquid statik metinleri, öznitelik değerleri ve filtre değerleri
- Snippet'lar
- Özel bileşen metinleri (önce bileşeni ayırmadığınız sürece)
Bu üçüncü madde bir örneği hak ediyor çünkü en sinsi olanı bu. Customer.io'nun kendi yerelleştirme belgelerinde şu satır geçiyor:
Bonjour {{ customer.first_name | default:"ami" }}ami kelimesi, sistemde ilk adı kayıtlı olmayan herkese gösterilen yedek ifadedir. Bu, doğrudan okuyucuya ulaşan gerçek bir metindir ve otomatik çevirinin dokunmadığı bir Liquid filtresinin içinde yer alır. Bunu Alman bir kitleye gönderdiğinizde, alıcılarınızın bir kısmı ami diye selamlanır. Her default: filtresindeki her yedek dizenin her varyant için tek tek elle çevrilmesi gerekir ve arayüzde sizi bu konuda uyaracak hiçbir şey yoktur.
Dikkate almanız gereken iki kısıtlama daha var: Varsayılan şablonu değiştirdiğinizde çeviriler otomatik olarak güncellenmez; ayrıca çevirili A/B testleri tek seferlik gönderimlerde çalışsa da API tetiklemeli yayınlarda veya otomasyonlarda işe yaramaz.
Snippet'lar için ayrı bir parantez açmak gerek. Yeniden kullanılabilir içerik mekanizması olan bu yapılar ({{snippets.your_snippet}}, varsayılan olarak her biri 16 KB), otomatik çeviri tarafından es geçilir. Customer.io, koşullu ifadelerin doğrudan snippet'ın içine yerleştirilmesini öneriyor:
{% if customer.language == 'fr' %}
Se désabonner
{% elsif customer.language == 'de' %}
Abmelden
{% else %}
Unsubscribe
{% endif %}Dolayısıyla bir Customer.io programı genellikle mesaj gövdeleri için yerleşik varyantlar ve paylaşılan her snippet'ın içinde manuel olarak yönetilen koşul yapılarından oluşan bir düzene dönüşür. Yapay zeka düğmesinin her şeyi kapsadığını varsaymadan önce bunu bilmekte fayda var.
Belgeler: Customer.io yerelleştirmesi
Klaviyo e-posta yerelleştirmesi
Klaviyo’nun Smart Translations özelliği, kampanya veya akış düzenleyicisi içerisinden mesaj içeriklerini 60’tan fazla dile makine çevirisiyle aktarır. Özelliği Ayarlar → Hesap → Çeviri sekmesindeki “Mesajları çevir” anahtarıyla etkinleştirebilirsiniz. Ücretli bir hesap gerektiren bu özellik, ücretsiz deneme sürümünde kullanılamaz.
Klaviyo'nun otomatik olarak çevrildiğini belirttiği içerikler belirli bir listeyle sınırlıdır: metin blokları, etiketler ve alternatif metinler. Konu satırları bu listede yer almaz; bu nedenle bir kampanyanın tamamen kapsandığını varsaymadan önce bunu hesabınızdan doğrulayın.
Dil belirleme işlemi varsayılan olarak profilin Yerel Ayarını (Locale) kullanır; bu bilgi mevcut değilse Ülke veya Dil bilgilerine başvurur. Klaviyo, BCP-47 kodlarını (en-GB, es-ES) ve ayrıca English veya French gibi düz metin değerlerini kabul eder.
Klaviyo ile çalışmayı keyifli kılan iki özellik var. İlki, hesap düzeyinde bir kez tanımlanan Çevrilmeyecekler listesi: Marka adları, ürün adları ve modelin asla dokunmasını istemediğiniz her türlü terim. Çoğu platformda bunun bir dengi yok; oysa bu liste, ürün adınızın on farklı yerel ayarda olduğu gibi korunması ile on farklı kelimeye dönüşmesi arasındaki o kritik farkı yaratıyor.
İkincisi ise öğe bazlı müdahale menüsüdür. Çevrilmiş herhangi bir öğe üzerinde Yeniden çevir, Kaynakla eşleştir, Düzenle ve Yoksay seçeneklerini kullanabilir, düzenleyicinin üst kısmındaki oklarla diller arasında geçiş yapabilirsiniz. Bu sayede inceleme süreci, metni baştan sona tekrar okumak yerine sadece işaretli öğeleri gözden geçirmeye dönüşür.
Klaviyo ayrıca, çevirmenlerle veya harici bir araçla çalışıyorsanız tercih edeceğiniz CSV tabanlı bir iş akışını da destekler. Çeviri → işlemler menüsü altında, Smartling veya Simple formatında Export CSV seçeneği bulunur. Sütunlar şunlardır: block_id (çevrilebilir her dizenin benzersiz kimliği), source (orijinal metin) ve dil koduyla adlandırılmış her dil için birer sütun. Kurallar katı ve mantıklıdır: block_id değerlerini düzenlemeyin veya silmeyin, satır eklemeyin ve source değerlerini değiştirmeyin.
Braze veya Customer.io'dan gelenlerin şaşırdığı bir nokta var: Klaviyo, Liquid değildir. Django şablon sözdizimini kullanır.
{% if person|lookup:'Loyalty Points' > 150 %}
Hey VIP! You've always got free shipping & free returns
{% elif person|lookup:'Loyalty Points' > 0 %}
You have {{ person|lookup:'Loyalty Points' }} points, and you just need 150 to become a VIP!
{% else %}
Have you heard about our VIP program? Join today on our website to start earning rewards.
{% endif %}Etiketler sizi yanıltacak kadar Liquid'e benzer; ancak elif ile elsif arasındaki o fark koca bir öğleden sonranızı mahvedebilir. Yedek değerli kişiselleştirme {{ first_name|default:'friend' }} şeklinde yazılır.
Belgeler: Klaviyo Smart Translations · Django sözdizimi
Mailchimp e-posta yerelleştirmesi
Mailchimp'in yerleşik bir çok dilli kampanya özelliği yoktur. Platform bunun yerine koşullu birleştirme etiketleri sunar; belgelenmiş yöntem, tüm dilleri tek bir e-postaya yazıp seçimi koşullu ifadelere bırakmaktır.
*|IF:MC_LANGUAGE=es|*
Spanish content here.
*|ELSEIF:MC_LANGUAGE=de|*
German content here.
*|ELSE:|*
Display English content for everyone else.
*|END:IF|**|MC_LANGUAGE|* etiketi kişinin dil kodunu, *|MC_LANGUAGE_LABEL|* ise okunabilir adını tutar. Mailchimp dili abonenin tarayıcısından algılamaya çalışır; ayrıca bu ayarı profil → Ayarlar → Dil altından kişi bazında veya içe aktarma sırasında toplu olarak belirleyebilirsiniz. *|EN``D:IF|* etiketinin hem IF hem de IFNOT bloklarını kapattığını unutmayın.
Genellikle asıl belirleyici olan bu tek kısıtlamadır. Konu satırı yanlış dilde olan yerelleştirilmiş bir e-posta, içeriğin bir önemi kalmadan daha en baştan açılma şansını kaybeder. Bu yüzden Mailchimp'te ikiden fazla dille çalışan çoğu ekip, eninde sonunda her dil için ayrı kampanya oluşturma noktasına gelir; bu durumda da koşullu birleştirme etiketi kullanmanın hiçbir faydası kalmaz. Bunu şablonu hazırladıktan sonra değil, planlama aşamasında bilmek çok daha iyidir.
Belgeler: Mailchimp içerik çevirme
Iterable e-posta yerelleştirmesi
Iterable'ın tam teşekküllü bir yerel ayar özelliği bulunuyor ve belgeleri, bu özelliğin ne anlama gelip gelmediği konusunda insanı ferahlatan bir açık sözlülüğe sahip:
Yerel ayarlar içeriği çevirmez.
Size bir varyant iskeleti sunulur; çevirileri siz sağlarsınız. Bunun karşılığında tüm varyantlar tek bir templateId paylaşır, böylece metrikleriniz on ayrı şablona dağılmak yerine tek bir merkezde toplanır. Bir kampanyayı dile göre kopyalara bölüp raporlamaya çalışmış olanlar için sadece bu bile kurulum zahmetine değer.
Alan adı tam olarak locale olmalıdır. Iterable; bu alanı languagePreference veya başka bir şekilde adlandırırsanız kullanıcıları varyantlarla eşleştiremeyeceğini açıkça belirtir. Yerel ayar adları ISO-639 ve ISO-3166 (fr-CA, fr-FR) standartlarını takip eder, üç harfli kodlar desteklenir ve yerel ayarlar oluşturulduktan sonra yeniden adlandırılamaz; bu yüzden yirmi tane oluşturmadan önce isimlendirme standardınıza karar verin. Yerel ayar alanı boşsa varsayılan yerelleştirme kullanılır; eşleşmeme durumu ise gönderimi atlamak veya varsayılanı göndermek arasında seçim yapan proje düzeyindeki bir ayarla yönetilir.
Iterable ayrıca bu işi kendi yöntemlerinizle (DIY) halletmenizi de açıkça tavsiye etmiyor:
Iterable esnek bir platformdur ve Handlebars veya Catalog kullanarak birden fazla dilde içerik oluşturmanıza olanak tanır; ancak bunlar yerelleştirme için en iyi uygulamalar değildir.
Şablon dili Handlebars'tır ve alan adları büyük-küçük harfe duyarlıdır. WYSIWYG düzenleyicisinde başınızı ağrıtabilecek küçük bir pürüz var: Koşullu ifadelerin HTML yorumları içine alınması gerekir, aksi takdirde düzenleyici bu ifadeleri bozar.
<!--{{#if activeUser}}-->
<div>Hi active user!</div>
<!--{{else}}-->
<div>Hi inactive user</div>
<!--{{/if}}-->Çeviri iş akışı (round-trip) için GET /api/templates/email/get isteği, şablon içeriğini çevirmenlerin kullanabilmesi için dışa aktarır.
Belgeler: Iterable çoklu dil desteği
Brevo e-posta yerelleştirmesi
Brevo, çeviriyi sizin yerinize yapan platformlar kategorisinde yer alır ve bu özellik özelinde Mailchimp'in en doğrudan rakibidir. Kişideki dil veya ülke koduna göre uyarlanan tek bir kampanya oluşturursunuz, Dil ekle seçeneğine tıklarsınız ve Brevo; manuel olarak veya yapay zeka asistanı Aura ile çevirmeniz için kampanyayı her dil için kopyalar.
Her dil için değiştirebileceğiniz öğelerin kapsamı çoğu platformdan daha geniştir: gönderen adı, konu satırı, önizleme metni ve e-posta tasarımının kendisinin yanı sıra yanıt adresi, Google Analytics takibi ve özel bir abonelikten çıkma sayfası. Konu satırı, tam da Mailchimp'in yapamadığı şey olduğu için özellikle kayda değerdir.
Belgelenmiş kısıtlamalar şunlardır: Dosya tabanlı çeviriler desteklenmez (bu nedenle CSV ile gidiş-dönüş yapılamaz; bu da dış bir çeviri sağlayıcısıyla çalışıyorsanız Brevo'yu seçenekler arasından eler), A/B testi kampanyalarıyla çalışmaz ve kayıtlı bölümlerin her dil için ayrı ayrı oluşturulması gerekir. Dil özelliği yapılandırılan dillerden hiçbiriyle eşleşmeyen kişiler, varsayılan sürümü alır.
Belgeler: Brevo çok dilli kampanyalar
Liquid, Handlebars ve birleştirme etiketleri: Aynen korunması gereken kısımlar
Hangi platformu kullanırsanız kullanın, asıl çeviri aşamasının tek bir kesin şartı vardır. Metniniz şablon sözdizimi içerir ve bu sözdiziminin her bir karakteri, girdiği haliyle aynen geri dönmelidir. Çevrilmiş bir {% endif %} ifadesi, gönderimin hata vermesi demektir.
Bu kılavuzda yer alan platformlardaki sözdizimi örnekleri şöyledir:
| Platform | Dil | Kişiselleştirme | Koşullu |
|---|---|---|---|
| Braze | Liquid | {{${first_name}}} | {% if %} / {% elsif %} / {% else %} / {% endif %} |
| Customer.io | Liquid | {{customer.first_name}} | {% if %} / {% elsif %} / {% else %} / {% endif %} |
| Klaviyo | Django | {{ first_name }} | {% if %} / {% elif %} / {% else %} / {% endif %} |
| Mailchimp | Birleştirme etiketleri | *|FNAME|* | *|IF:X|* / *|ELSEIF:X|* / *|ELSE:|* / *|END:IF|* |
| Iterable | Handlebars | {{firstName}} | {{#if}} / {{else}} / {{/if}} |
| Brevo | Brevo Şablon Dili | {{ contact.FIRSTNAME }} | {% if %} / {% else %} / {% endif %} |
Bu süreçte yaşanan aksaklıkların neredeyse tamamı üç temel hata türünden kaynaklanır.
Model token'ı çevirir. Geriye {{ prénom }} veya {% si %} döner; sonuçta gönderim başarısız olur ya da metin olduğu gibi ham haliyle görünür. Kullanmaya değer her araç, metin modele ulaşmadan önce token'ları maskeler ve sonrasında geri yükler; böylece model bunları asla kelime olarak görmez.
Model token'ın yerini değiştirir. Diller arasında sözdizimi doğal olarak değiştiği için bir token'ın yerinin değişmesi gerekir. Sorun, token'ın yanlış yan cümleciğe kayması veya bir {% if %} ile {% endif %} etiketinin sıralamasının bozulmasıdır. Konum kritiktir; çözüm, çıkan token setinin giren setle eşleşip eşleşmediğini kontrol etmek ve eşleşmiyorsa bloğu yeniden çalıştırmaktır.
Token sayısı değişir. En tehlikelisi eksik bırakılan token'lardır; çünkü e-posta yine de oluşturulur, ancak bir isim veya bir koşul dalı eksik kalır. Bu yüzden sayım yapmak, gözle kontrol etmekten çok daha önemlidir.
Bu üç durumu da kapsayan temel kural şudur: koşullu dallar ayrı dizelerdir. Bu satırda birbirinden bağımsız iki metin parçası yer alır; içeriğin tamamının tek bir yığın halinde önüne konduğu bir çevirmen veya model, her bir parçanın bağlamıyla birlikte ayrı ayrı sunulduğu duruma kıyasla her iki bölümde de daha kötü bir iş çıkaracaktır:
{% if ${loyalty_tier} == 'gold' %}Gold members get an extra 10%.{% else %}Join Gold for an extra 10%.{% endif %}HTML e-postalar ve dize tabloları iki farklı iştir
Bu yolda tüm kurulumunuzu belirleyen bir yol ayrımı vardır ve insanlar bunu genellikle yolun yarısında fark ederler.
Bazı e-posta içerikleri birer belgedir: Bir HTML şablonu, oluşturulmuş bir e-posta ya da yukarıdan aşağıya okunan, belirli bir yapısı ve akışı olan bir metin. Bunların bağlantılı bir metin olarak çevrilmesini istersiniz; çünkü başlık ve altındaki gövde metni bir bütündür. Her iki kısmı da görebilen bir çevirmen, bu kısımları tek başına gören birine kıyasla çok daha isabetli kararlar verir.
Diğer e-posta içerikleri ise bir dize tablosudur: Her satırın bağımsız olduğu anahtarlı bir liste. cta_``button, subject_line, footer_unsub. Bunlar, metnin kendisinden daha kritik meta verilerle birlikte gelir: Asla değişmemesi gereken bir anahtar, bir bağlam notu ve genellikle bir karakter sınırı; çünkü uzun bir konu satırı gelen kutusunda yarıda kesilir.
Braze CSV'leri, Klaviyo CSV'leri ve yazılım dünyasındaki tüm yerelleştirme dosyası formatları (gettext PO, XLIFF) birer dize tablosudur. HTML şablonlarınız ise birer belgedir. Bir dize tablosuna belge muamelesi yaparsanız anahtarları kaybedersiniz; bir belgeye dize tablosu muamelesi yaparsanız metni birbirinden kopuk parçalara ayırmış olursunuz.
İşte bu yüzden Transept'teki dize dosyası desteğini, belge içe aktarma özelliğine dahil etmek yerine başlı başına ayrı bir yol olarak kurguladık. E-posta metinlerini içeren bir CSV dosyası; anahtar, kaynak ve çeviri sütunlarından oluşan bir ızgara yapısında aktarılır; karakter sınırı canlı bir sayaç olarak sunulur ve her satıra bir bağlam notu eklenir.

En önemli özellik, dosyanın sisteme girdiği yapıyla geri çıkmasıdır. Sonradan üzerinde elle yeniden düzenleme yapmanız gereken bir dosya yerine; anahtarlarınızın ve sütunlarınızın tam da platformun beklediği düzende olduğu, çevrilmiş orijinal dosyayı dışa aktarırsınız.
Transept'e e-posta desteği eklerken öğrendiklerimiz
Tam olarak bu iş akışı için dize dosyası içe aktarma özelliğini kullanıma sunduk ve bu süreç, başka hiçbir yerde yazılı olarak görmediğim detayları gün yüzüne çıkardı. Bunlar; kendi kodumuzdan ve test çalışmalarımızdan elde ettiğimiz, tamamen bize ait bulgulardır.
Teknik olarak "50% off" bir printf dönüşümüdür
Yazılım dizelerinde genellikle printf yer tutucuları kullanılır: %s, %d, %1$s. Bunları çeviri öncesinde maskeliyorsanız, akla ilk gelen regex printf'in tüm bayrak kümesini kabul eder; buna boşluk bayrağı da (% d pozitif sayıların önüne bir boşluk ekler) dahildir. Bu, geçerli bir printf kullanımıdır ve bunu kabul etmek savunulabilir bir tercihtir.
Pazarlama metinleri içinse bu tam bir felakettir. Boşluk bayrağı kabul edildiğinde, 50% off bir eşleşme içerir: % o dizisi, boşluk bayraklı bir sekizlik (octal) dönüşüm olarak ayrıştırılır. 100% organic için de durum aynıdır. Promosyon e-postalarında en sık rastlanan kalıp olan Up to 70% off için de bu durum değişmez.
İki yöntemi de denedik:
| Girdi | Katı desen | Boşluk bayrağıyla |
|---|---|---|
İlk siparişinizde %50 indirim | eşleşme yok | % o |
%100 organik pamuk | eşleşme yok | % o |
Merhaba %s, %%%d tasarruf ettiniz | %s, %d, %% | %s, %d, %% |
% o dizisini maskelemek, indirim satırınızı bir yer tutucuya dönüştürür ve modele bozulmuş bir cümle sunar. Boşluk bayrağını bilinçli olarak reddediyoruz ve hiçbir şey kaybetmiyoruz; zira hiçbir gerçek dize tablosu bu bayrağı kullanmaz.
Braze'in kişiselleştirme etiketinde üç adet kapatma parantezi bulunur
Bunu bu kılavuzu yazarken fark ettik; bu da kılavuz hazırlamanın ne kadar faydalı olduğunun iyi bir kanıtı.
Braze'in söz dizimi {{${first_name}}} şeklindedir. Kapatma parantezlerini sayalım: Özniteliğin kendi } işareti ve ardından Liquid çıktı etiketini kapatan iki adet parantez. Arka arkaya üç tane.
Hemen hemen tüm Liquid tokenizer'lar, ilk }} işaretini gördüğü anda duracak şekilde tarama yapar. {{``${first_name}}} söz dizimiyle karşılaşıldığında bu durum, parantezin bir karakter erken kapanmasına yol açar: Sistem {{${first_name}} kısmını yakalar ve çevrilecek metnin içinde yalın bir } bırakır. Belirteç işlenmiş gibi görünür; ancak o başıboş parantez modele düz metin olarak gider ve oradan yeri değişmiş, yinelenmiş veya tamamen kaybolmuş şekilde geri döner.
{{${first_name}}}, your spring sale starts now
non-greedy scan → token: {{${first_name}} leftover: "}, your spring sale starts now"
brace-aware scan → token: {{${first_name}}} leftover: ", your spring sale starts now"Bizim aracımız da tam olarak böyle yaptı. Hatayı bulduk, belirteç içinde tek düzeyli iç içe yapıya izin verecek şekilde düzelttik ve Braze'in tam söz dizimini test setimize ekledik. Kendi e-posta araçlarınızı geliştiriyorsanız, özellikle {{${attribute}}} yapısıyla test edin; zira yalın {{ attribute }} formu sorunsuz çalışır ve hatayı tamamen gizler.
Yer tutucuların içindeki tırnak işaretleri JSON yanıtlarını bozar
Bir dize grubunu bir modele gönderip yanıtı JSON ile sınırlandırdığınızda, yanıt dizesindeki kaçışsız bir " işareti dizeyi erkenden kapatır ve grubun geri kalanının kaybolmasına yol açar. Tırnaklı öznitelikler içeren yer tutucularda bu sorunla karşılaştık ve bir modelle yaptığımız denemelerin yaklaşık %58'inde bu durumu yeniden ürettik.
Çözüm, istemde daha iyi kaçış karakteri talimatları vermek değil, iletim formatını tırnaksız hale getirerek hatanın oluşmasını engellemektir: Model yer tutucuları yalnızca tırnaksız haliyle görür, tırnaklı kanonik form ise sonradan geri yüklenir. Bir modele JSON yapısını bozmamasını söylemek çoğu zaman işe yarar; bu da hataları fark edemeyeceğiniz için olabilecek en kötü güvenilirlik profilidir.
Fuzzy kayıtlar birer sinyaldir, çeviri değil
Dizeleriniz gettext PO dosyalarından geliyorsa, kayıtlar "bu otomatik olarak eşleştirildi, henüz bir insan tarafından onaylanmadı" anlamına gelen bir fuzzy bayrağı taşır. Fuzzy kayıtları tamamlanmış çeviriler olarak değerlendirmek, bir yığın tahmini onaylanmış iş olarak sisteme dahil etmek demektir.
Bu kayıtları veri besleme sürecinin dışında tutar, sıfırdan çevirir ve geri gönderirken fuzzy bayrağını kaldırırız; çünkü o aşamada kayıt artık gözden geçirilmiştir ve bayrak geçerliliğini yitirmiştir.
E-posta kampanyası yerelleştirmede en iyi uygulamalar
Sorunsuz bir süreci sancılı olandan ayıran alışkanlıklar; kabaca ne kadar dertten kurtardıklarına göre sıralanmıştır.
Yerel ayar kodlarınıza bir kez, profil düzeyinde karar verin. İki harfli veya bölge belirteçli olsun ve her yerde tutarlı kalsın. "Çeviri görünmedi" vakalarının çoğu, nl-BE profili ile nl mesajının karşılaşmasından kaynaklanır.
Herhangi bir yere göndermeden önce her dize için bağlam yazın. Bir e-tabloda Shop the sale ifadesini gören çevirmen, bunun bir düğme mi, başlık mı yoksa bağlantı mı olduğunu veya sığması gereken on sekiz karakterlik bir sınırı olup olmadığını bilemez. Bağlam veya açıklama alanı sunan her platform, aslında sizden çıktı kalitesini en çok artıran şeyi istiyordur; ancak neredeyse hiç kimse bu alanları doldurmaz.
Karakter sınırlarını birincil bir kısıtlama olarak kabul edin. Almanca metinler, İngilizceye kıyasla yaklaşık 1,5 ila 2 kat daha fazla yer kaplar. İngilizceye sığan bir CTA taşma yapar; sığan bir konu satırı ise gelen kutusunda kelime ortasında kesilir. Sınırı dizeyle birlikte iletin ki çeviriyi yapan kişi sayacı görebilsin.
Çevrilmeyecekler listesi tutun. Ürün adları, marka terimleri, özellik adları. Klaviyo'da bu özellik yerleşik olarak bulunur; diğer platformlarda ise sözlüğünüzde yer alır. Her iki durumda da, ürün adınızın altı farklı varyasyonuyla karşılaştıktan sonra değil, ilk çalıştırmadan önce bu listeyi hazırlayın.
Yedek değerleri çevirin. Her default: filtresi, her {% else %} dalı, isim eksik olduğunda görünen her "Merhaba" ifadesi. Bunlar önizlemede asla görünmeyen, dolayısıyla asla gözden geçirilmeyen ve hakkında en az bilgiye sahip olduğunuz alıcılara giden dizelerdir.
Kararlarınızı farklı gönderimlerde tekrar kullanın. Kampanya metinleri sürekli tekrarlanır: aynı alt bilgi, aynı abonelikten ayrılma satırı, her yıl aynı sezonluk kurgu. Bir çeviri belleği, "İndirimden alışveriş yap" ifadesini bir kez karara bağlamanız ve üç farklı çalışmanın üç farklı karar vermesi sonucu üç varyasyona bölünmesi yerine, sonraki her kampanyada bu ifadenin korunması demektir.
Asıl gönderimden önce her dilde test gönderimi yapın. Her yerel ayarda gerçek bir profil kullanarak şablonu işleyin. Editörde düzgün görünen koşullu ifadeler, bazen ancak şablon işlendiğinde ortaya çıkan hatalara yol açabilir; bu adım, çevrilmemiş bir yedek değeri veya bozuk bir dalı henüz hiçbir maliyeti yokken yakalamanızı sağlar.
Sıkça sorulan sorular
E-posta yerelleştirme nedir?
E-posta yerelleştirme; bir e-posta kampanyasının metin, konu satırı, ön başlık, kişiselleştirme yedek değerleri ve hedef yerel ayarın biçimlendirme kurallarıyla birlikte başka bir dile ve pazara uyarlanması sürecidir. Bu süreç; aynen korunması gereken şablon söz dizimlerinin (birleştirme etiketleri, Liquid veya Handlebars koşullu ifadeleri) yanı sıra konu satırı uzunluğu gibi çevirinin uymak zorunda olduğu kısıtlamaları da içerdiği için düz çeviriden ayrılır.
Hangi e-posta platformları kampanyaları otomatik olarak çevirir?
Klaviyo (Smart Translations, 60+ dil), Customer.io (e-posta, SMS, WhatsApp, anlık bildirim ve uygulama içi mesajlarda yapay zeka ile otomatik çeviri) ve Brevo (Aura asistanı aracılığıyla) çevirileri doğrudan editör içinde üretir. Braze ve Iterable yerel ayar altyapısı sunar ancak çevirileri sizin sağlamanızı bekler. Mailchimp'in yerleşik bir çok dilli kampanya özelliği bulunmaz; bunun yerine koşullu birleştirme etiketlerine dayanır.
Mailchimp konu satırını çevirebilir miyim?
Hayır. Mailchimp belgeleri, koşullu birleştirme etiketleri konu alanında çalışmadığı için konu satırını çevirmenin mümkün olmadığını belirtiyor. Mailchimp üzerinden yerelleştirilmiş konu satırları göndermek için, kişilerin dil alanına göre segmente edilmiş, her dil için ayrı bir kampanya oluşturmanız gerekir.
Liquid etiketlerimin çeviri sırasında bozulmasını nasıl önlerim?
Metin çeviri modeline ulaşmadan önce tokenları maskeleyerek modelin bunları kelime olarak görmesini engelleyin; ardından bu tokenları geri yükleyin ve sonucu kabul etmeden önce çıktıdaki token setinin girdiyle eşleştiğini doğrulayın. Tüm {% if %}...{% endif %} satırını tek bir yığın halinde iletmek yerine her bir koşullu dalı ayrı bir dize olarak çevirmek de kaliteyi artırır; çünkü bu sayede her dal, kendi başına bağımsız bir cümle olarak çevrilmiş olur.
HTML e-posta ile dize tablosu arasındaki fark nedir?
HTML e-posta bir dokümandır: Yapısal bir bütünlüğe sahip, birbiriyle bağlantılı bir metindir; bağlamın başlık ve gövde arasında korunması için bir bütün olarak çevrilmesi en iyisidir. Dize tablosu ise her satırın bağımsız olduğu; asla değişmemesi gereken bir anahtar, genellikle bir bağlam notu ve çoğu zaman bir karakter sınırı içeren anahtarlı bir listedir. Braze ve Klaviyo CSV dışa aktarımları, gettext PO dosyaları ve XLIFF formatlarının tümü dize tablosudur. Bu iki tür farklı yaklaşım gerektirir: Dize tablosuna doküman muamelesi yapmak anahtarların kaybolmasına, dokümana dize tablosu muamelesi yapmak ise metin akışının parçalanmasına neden olur.
Çeviriler için CSV dışa aktarımını mı yoksa platformun API'sini mi kullanmalıyım?
Çeviri bir insan veya harici bir tedarikçi tarafından yapılıyorsa CSV pratik bir seçimdir; Braze ve Klaviyo'nun belgelerinde yer verdiği yöntem de budur. Süreç belirli bir takvime göre tekrarlanıyorsa veya hacim manuel dosya yönetiminin bir darboğaz oluşturacağı kadar yüksekse, API tabanlı bir süreç daha iyidir. Braze bir çeviri API'si sunar (bu yazının kaleme alındığı sırada erken erişim aşamasındaydı) ve Iterable şablon içeriğini GET /api/templates/email/get üzerinden erişime açar. Brevo ise ikisini de desteklemez: Dosya tabanlı çeviri özelliği yoktur, bu nedenle kampanyaların arayüz üzerinden çevrilmesi gerekir.
Tek bir e-posta kampanyası kaç dili destekleyebilir?
Bu durum platforma göre değişir. Braze, çalışma alanı başına 200'e kadar yerel ayara ve mesaj başına 200 çeviri etiketine izin verir. Klaviyo, Smart Translations aracılığıyla 60'tan fazla dili kapsar. Customer.io, birkaç yüz dil ve dil-bölge kodunu kabul eder. Pratikte kısıtlayıcı faktör nadiren platform limitidir; asıl mesele, kaynak metin değiştikçe kaç dili denetleyebileceğiniz ve güncel tutabileceğinizdir.
Yazar

Transept'in kurucu ortağı. İngiliz Dili ve Edebiyatı alanında üç derece – Kyiv, Ostrava ve Salzburg'da bir yıl – ve yazı hayatının büyük kısmını İngilizce sürdüren bir Ukraynalı. Yapay zekâ dünyasına prompt mühendisi olarak adım attı, ardından ürün ve yaşam döngüsü pazarlamasına yöneldi. Gerçek insanlar hakkında yarı kurgusal hikâyeler yazıyor ve diller arasında nelerin kaybolduğu sorusunun etrafında dönüp duruyor.

