Sözde Yerelleştirme (Pseudo-Localization) Nedir? Çeviriden Önce Hata Bulmak

Bir arayüzün çeviriye hazır olup olmadığını anlamanın en ucuz yolu, henüz kimse çeviri yapmadan denemektir. Sözde yerelleştirme tam olarak bunu yapar: özgün metinleri sahte ama gerçekçi karşılıklarla değiştirip ekranın ne hâle geldiğini gösterir.

İçindekiler

Tanımı şöyle özetlenebilir: yazılım ya da uygulamadaki özgün dizelerin, hedef dillerin karakterlerini temsil eden ve belirli bir oranda uzatılmış dizelerle otomatik olarak değiştirilmesi (Schäler 2012, aktaran Jiménez-Crespo 2024, s. 50). Amaç, çevirinin ürün üzerinde yaratacağı etkiyi önceden görmektir.

Çeviri satın alan taraf için bu, teknik bir ayrıntıdan fazlasıdır. Testin yapılıp yapılmaması, projede kaç kez geri dönüleceğini ve teslim tarihinin tutup tutmayacağını doğrudan etkiler.

Sözde yerelleştirme nedir, nasıl çalışır?

Yöntem basittir. Ürünün kaynak dosyalarındaki metinler alınır, önceden tanımlanmış bir algoritmayla dönüştürülür ve yerine konur. Dönüşüm genellikle iki şey yapar: dizenin uzunluğunu artırır ve karakterlerine aksan ya da farklı alfabelerden işaretler ekler.

Ortaya çıkan metin okunabilir bir dil değildir ama tanınabilir kalır. Bir düğmenin üzerinde “Kaydet” yerine uzatılmış ve işaretlenmiş bir sürüm görünür. Böylece ekranın hangi bölümünün taştığı, hangi metnin kesildiği bir bakışta anlaşılır.

Testin ikinci faydası, çevrilmeyen metinleri ortaya çıkarmasıdır. Ekranda dönüşüme uğramamış, olduğu gibi duran bir ifade varsa o metin kaynak dosyalarda değil, kodun içine gömülü demektir. Bu, çeviri başlamadan önce mutlaka düzeltilmesi gereken bir bulgudur.

Aynı mantık “sözde dil” adı verilen uydurma dillerle de uygulanır. Bunlar gerçek bir dile karşılık gelmez; sağdan sola yazım, aksanlı karakter veya emoji desteği gibi belirli özellikleri sınamak için tasarlanmıştır. Böylece hedef dil henüz belli değilken bile ürünün dayanıklılığı ölçülebilir.

Testin en pratik yanı, hiçbir dil bilgisi gerektirmemesidir. Ekrana bakan kişi Almanca ya da Arapça bilmek zorunda değildir; kesilmiş bir metni, üst üste binen iki düğmeyi ya da kutunun dışına taşmış bir başlığı görmek yeterlidir. Bu da testi ürün ekibinin doğrudan yapabileceği bir işe dönüştürür.

Neden gerçek çeviriden önce yapılır?

Yerelleştirmede hatanın maliyeti bulunduğu aşamaya göre katlanır. Şelale modelinde sorun süreç ilerledikten sonra ortaya çıkarsa çözümü hem pahalı hem yavaş olur; geliştiriciler çoktan başka bir işe geçmiş olabilir (Jiménez-Crespo 2024, s. 57).

Sözde yerelleştirme bu riski öne çeker. Ekran taşmaları, kesilen başlıklar ve bozulan hizalamalar henüz tek bir kelime çevrilmeden görünür hâle gelir. Düzeltme, tasarımın hâlâ esnek olduğu bir anda yapılır.

Bunun ticari karşılığı şudur: aynı hatayı on beş dilde ayrı ayrı düzeltmek yerine bir kez kaynakta düzeltirsiniz. Dil sayısı arttıkça bu testin getirisi doğrusal değil, çarpan etkisiyle büyür.

Test ayrıca teklif sürecini de sağlamlaştırır. Bulgular elinizdeyken tedarikçiden alacağınız fiyat, tahmine değil ölçüme dayanır ve proje ortasında kapsam değişikliği ihtimali azalır. Mühendislik saatlerinin ne kadar tutacağı da böylece tahminden çıkıp somut bir kaleme dönüşür.

Sözde dil türleri ve ne sınadıkları

Büyük geliştirme ortamları bu testi hazır seçenek olarak sunar. Apple’ın geliştirici araçlarında tanımlanan sözde dil türleri, hangi sorunun hangi yöntemle sınandığını iyi gösterir (Jiménez-Crespo 2024, s. 50; Apple Developer belgeleri).

Sözde dil	Ne yapar	Neyi sınar
Çift uzunluk	Metinleri iki katına çıkarır	Kutuların büyümeye uyum sağlaması
Sağdan sola	Yazı yönünü ters çevirir	Arayüzün aynalanabilmesi
Aksanlı	Karakterlere aksan ekler	Uzayan harflerde satır yüksekliği
Duygusal	Metne emoji yerleştirir	Simgelerin doğru görüntülenmesi
Sınırlı dize	Metni işaretlerle çevreler	Kırpılan ve kesilen metinler

Tablodaki her satır aslında ayrı bir soruya karşılık gelir. Arayüzünüz Almancaya çevrildiğinde büyüyecek metni taşıyabiliyor mu? Arapça veya İbranice bir sürüm istendiğinde düzen aynalanabiliyor mu? Bu sorular sonradan sorulduğunda cevabı pahalı olur.

Uzama oranları da rastgele seçilmez. Sektörde kullanılan ölçütlere göre İngilizceden Almancaya çeviride metin belirgin biçimde uzayabilirken Japonca ya da Korece gibi dillerde kısalabilir (Eriksen 2019 verileri). Test bu farkları taklit eder.

Hangi sorunları yakalar?

Testin bulguları genellikle şu başlıklarda toplanır:

1. Kutuya, düğmeye veya menüye sığmayan metinler.
2. Kaynak dosyaya çıkarılmamış, koda gömülü kalmış ifadeler.
3. Parçalara bölünüp çalışma anında birleştirilen ve çeviride bozulacak cümleler.
4. Aksanlı harflerde kırpılan satırlar ve bozulan satır aralıkları.
5. Sağdan sola yazımda ters dönmeyen simgeler, oklar ve hizalamalar.

Bu listedeki üçüncü madde en sinsi olanıdır. Kaynak dilde doğru görünen “Toplam” ve “adet” parçaları birleştiğinde Türkçede farklı bir sıra gerektirebilir ve çevirmen elindeki parçayı tek başına gördüğü için sorunu fark edemez.

Bulguların çoğu tasarım tarafında çözülür: sabit genişlik yerine esnek düzen, kısaltma yerine daha kısa etiket, tek satır yerine iki satıra izin veren kutu. Hiçbiri çeviri kararı değildir; hepsi ürün kararıdır.

Duyarlı tasarım bu testi gereksiz kılar mı?

Günümüzde çoğu site ve uygulama, ekran boyutuna göre kendini ayarlayan duyarlı tasarımla geliştiriliyor. Bu yaklaşım yazı sistemleri arasındaki uzama ve kısalma sorunlarının önemli bölümünü çözüyor (Jiménez-Crespo 2024, s. 49).

Ancak her zaman yeterli olmuyor. Duyarlı düzen genişliği yönetir, anlamı ve okunabilirliği yönetmez. Üç kelimelik bir menü başlığı iki satıra düştüğünde teknik olarak sorun yoktur, ama görsel hiyerarşi bozulur ve kullanıcı tereddüt eder.

Sabit genişlikte kalmak zorunda olan bileşenler de vardır: bildirim kutuları, tablolar, grafik etiketleri, e-posta şablonları. Bu alanlarda sözde yerelleştirme hâlâ en hızlı uyarı mekanizmasıdır.

Kısacası duyarlı tasarım testin yerini almaz, testin bulacağı hata sayısını azaltır. İkisi birbirini tamamlar.

Test ne zaman ve hangi sıklıkla çalıştırılmalı?

İlk çalıştırma için doğru an, ürün tasarımı oturduktan sonra ama ilk çeviri siparişi verilmeden öncedir. Bu noktada arayüz değişiklikleri hâlâ ucuzdur ve bulguların hepsi tek bir düzeltme turunda toplanabilir. Testi çeviriden sonra çalıştırmak, aynı işi iki kez yapmak anlamına gelir.

Sürekli yayın yapan ürünlerde ise tek seferlik bir kontrol yetmez. Her sürümle yeni ekranlar ve yeni metinler eklendiği için testin derleme sürecine bağlanması ve otomatik çalışması tercih edilir. Böylece yeni eklenen koda gömülü bir metin, üretim ortamına ulaşmadan yakalanır.

Kapsamı belirlerken ekranların tamamını değil, riskli olanları önceliklendirmek mantıklıdır. Ödeme akışı, form doğrulama uyarıları, bildirim metinleri ve e-posta şablonları hem en kritik hem de en sık taşan alanlardır.

Sonuçların nasıl raporlanacağını da baştan konuşmak gerekir. Ekran görüntüsü, ilgili dizenin kimliği ve önerilen düzeltmeyi bir arada tutan basit bir tablo, geliştirici ile dil ekibi arasındaki yazışma trafiğini belirgin biçimde azaltır.

Testin sınırları nerede biter?

Sözde yerelleştirme teknik dayanıklılığı ölçer, anlamı ölçmez. Yanlış terim seçimi, hedef pazarda uygunsuz bir görsel, kültürel olarak yanlış bir renk veya simge bu testte görünmez. Bunlar için ayrı bir kültürel kabul incelemesi gerekir.

Test aynı zamanda bağlam sorununu çözmez. Çevirmenin bir dizeyi hangi ekranda gördüğü, bir kelimenin başlık mı düğme mi olduğu hâlâ ayrı bir bilgi ister. Bunun için ekran görüntüsü veya bağlam içinde çalışma imkânı sağlayan araçlar kullanılır.

Bu yüzden sözde yerelleştirmeyi tek başına bir kalite güvencesi olarak sunan bir tedarikçi eksik konuşuyor demektir. Test, yerelleştirme öncesi kontrol listesinin bir maddesidir; listenin tamamı değildir.

Son bir sınır da beklentiyle ilgilidir. Test, uzama oranlarını ortalama değerlere göre taklit eder; gerçek çeviride bazı cümleler bu ortalamanın çok üstüne çıkabilir. Bu nedenle sonuç “sorun yok” değil, “bilinen sorunlar temizlendi” biçiminde okunmalıdır.

Türkiye bağlamı

Türkçe, sözde yerelleştirmenin işe yaradığı tipik dillerden biridir. Sondan eklemeli yapı nedeniyle kısa bir İngilizce etiket Türkçede ek almış uzun bir öbeğe dönüşebilir. “Clear filters” iki kelimeyken “Filtreleri temizle” daha çok yer ister ve dar bir düğme bunu kaldırmaz.

Türkçeye özgü karakterler ikinci bir sınav yaratır. Noktalı ve noktasız “i” harfleri, büyük-küçük harf dönüşümünde yanlış sonuç verebilir; ğ, ş ve ç harfleri bazı yazı tiplerinde satır yüksekliğini değiştirir. Aksanlı sözde dil bu sorunları hızla ortaya çıkarır.

Türkiye’den yurt dışına açılan yazılımlarda ise ters yönde bir risk var. Ürün Türkçe geliştirilip İngilizceye çevrildiğinde metin kısalır ve ekranlar boş görünür; Arapça sürüm istendiğinde ise yazı yönü sorunu tasarımın en başına döner. Testi iki yönlü çalıştırmak faydalı olur.

Bu sizin için ne anlama geliyor?

Sözde yerelleştirme, çeviri bütçenizi doğrudan azaltmaz; ama çevirinin çevresindeki düzeltme ve gecikme maliyetini düşürür. Sipariş verirken şu adımları izlemek işinizi kolaylaştırır:

1. Geliştirici ekibinizden çeviri başlamadan önce bir sözde yerelleştirme denemesi isteyin.
2. Çıkan ekran görüntülerini yerelleştirme kitine ekleyip tedarikçinizle paylaşın.
3. Koda gömülü çıkan metinlerin listesini düzeltilecek işler arasına alın.
4. Karakter sınırı olan alanları çevirmene önceden bildirin.

Yerelleştirme öncesi hazırlık konusunda daha fazla içeriğe bilgi merkezimizden ulaşabilirsiniz. Ürününüzün hazır olup olmadığını birlikte değerlendirmek isterseniz teklif sayfamızdan dosya yapınızı paylaşabilirsiniz.

Sık sorulan sorular

Sözde yerelleştirme çeviri yerine geçer mi?

Hayır. Üretilen metin okunabilir bir dil değildir; amacı anlam taşımak değil, arayüzün farklı dillere dayanıp dayanmadığını sınamaktır. Gerçek çeviri süreci bu testten sonra normal şekilde işler.

Bu testi kim yapar?

Genellikle geliştirici veya yerelleştirme mühendisi yapar, çünkü test kaynak dosyaların ve derleme sürecinin içinde çalışır. Çeviri bürosu testin yapılmasını önerebilir ve çıkan bulguları yorumlayabilir, ama uygulama çoğunlukla ürün ekibindedir.

Küçük bir web sitesi için de gerekli mi?

Ölçeği küçülterek uygulanabilir. Birkaç sayfalık bir sitede metinleri yaklaşık yüzde otuz uzatılmış örneklerle doldurup ekranı kontrol etmek bile çoğu taşma sorununu önceden gösterir.

Sözde yerelleştirme hangi hataları yakalayamaz?

Anlamla ilgili olanları. Yanlış terim seçimi, kültürel olarak uygunsuz bir görsel veya hedef pazara aykırı bir ifade bu testte görünmez. Test yalnızca teknik ve görsel dayanıklılığı ölçer.

Kaynaklar

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, s. 49-50. · Schäler, R. (2012). “Localization”. Routledge Encyclopedia of Translation Studies. · Apple Developer, “Preparing Your Interface for Localization” belgeleri. · Eriksen (2019), metin uzama oranları derlemesi.