01. Yazılım yerelleştirmesinde operasyonel olarak ne yapıyoruz?
Belge tercümesinden farklı bir iş yapıyoruz. Elimize bir PDF değil; içinde key–value çiftleri, placeholder'lar, çoğul kuralları ve teknik notlar olan kaynak dosyalar geliyor. Bu dosyaları parçalamadan, anahtarları bozmadan ve değişken alanları (`{name}`, `%s`, `%1$d`) yerinde tutarak hedef dile çeviriyoruz.
Çalışma genelde üç katmanda ilerler. Önce kaynak dosyaları ve mevcut terminolojiyi inceleriz; varsa eski çevirilerden bir bellek (TM) oluştururuz. Ardından çeviri ve editör revizyonu yapılır; UI bağlamı belirsiz kaldığı yerlerde ekran görüntüsü veya kısa açıklama isteriz. Son aşamada çeviri uygulamaya entegre edildikten sonra LQA testi yapılır: metnin butona sığıp sığmadığı, sayı–tarih biçiminin doğru olup olmadığı, RTL dillerde hizalama ve kültürel uyum kontrol edilir.
Kısacası iş, yalnızca metin değil; metnin yazılım içindeki davranışıdır.
02. Hangi dosya formatlarıyla çalışıyoruz?
Yazılım dünyasında “tek standart” yok; bu yüzden formatı sizin tarafınızda zorlamıyoruz. Dosyayı olduğu gibi alıp olduğu gibi geri veriyoruz.
Sık çalıştığımız formatlar:
- Web ve genel: JSON, YAML, XLIFF 1.2/2.0, gettext (.po/.pot), CSV, XML
- Mobil: Android `strings.xml` (çoğul ve `plurals` dahil), iOS `Localizable.strings` ve `.stringsdict`, Apple `.xliff` export
- Masaüstü/oyun: `.resx`, `.properties`, Unity `LocalizationTable`, Unreal `.po`
- E-ticaret ve CMS: Shopify locale JSON, WordPress `.po`/`.mo`, Magento CSV, Sanity/Strapi export
- Belge tipi yardımcı içerik: Markdown, HTML, sürüm notları, App Store / Play Store metadata
Gerekirse repo erişimiyle (GitHub/GitLab) PR tabanlı çalışırız; tercih ederseniz dosyaları paylaşılan klasör üzerinden alıp veririz. Placeholder formatları, ICU MessageFormat ve HTML etiketleri çeviri sırasında korunur, çıktı dosyası geliştirici tarafında ek temizlik gerektirmeyecek şekilde teslim edilir.
03. TMS, terminoloji ve çeviri belleği
Bir yazılım projesi uzun ömürlüdür; aynı kelimeyi her sürümde farklı çevirmek hem kullanıcı deneyimini hem de bakım maliyetini bozar. Bu yüzden her projede iki yapı kurarız: bir terminoloji listesi (glossary) ve bir çeviri belleği (TM).
Glossary, ürününüzün marka ve teknik sözlüğüdür. Örneğin “Dashboard” bazı ürünlerde “Pano”, bazılarında “Kontrol Paneli”, bazılarında olduğu gibi bırakılır; bu kararı baştan veririz, sürüm boyunca tutarız. TM ise daha önce çevrilmiş cümleleri saklar; küçük bir kelime değiştiğinde tüm cümleyi yeniden çevirmek gerekmez, yalnızca fark ücretlendirilir.
TMS tarafında esnek çalışıyoruz. Crowdin, Lokalise, Phrase, Smartling veya Weblate kullanıyorsanız oradan devam ederiz; bir aracınız yoksa bizim sistemimiz üzerinden ilerleriz. Tercih, geliştirici ekibinizin alışkanlığına göre belirlenir — biz projeyi sizin akışınıza taşırız, tersini değil.
04. In-context review ve LQA testi
Yazılımda çevirinin “doğru” olması yetmez; arayüzde doğru görünmesi gerekir. Bu yüzden iki aşamalı bir kalite katmanı uygularız.
In-context review çeviri aşamasında olur. Ekran görüntüsü, Figma bağlantısı veya staging URL'i paylaşırsanız çevirmen metni bağlamı görerek seçer. “Save” butonu için “Kaydet” mi “Kaydı Oluştur” mu uygun, bunu boş bir tabloda değil, gerçek ekranda kararlaştırırız.
LQA (Linguistic Quality Assurance) ise çeviri uygulamaya entegre edildikten sonra gelir. Test cihazında ya da staging ortamında menüleri, hata mesajlarını, e-posta şablonlarını ve onboarding akışını gezerek şunlara bakarız: metin butona sığıyor mu, satır taşması var mı, çoğul kuralları doğru tetikleniyor mu, tarih ve para birimi biçimi yerel beklentiyi karşılıyor mu, sağdan sola dillerde (Arapça, İbranice) hizalama bozulmuş mu. Bulgular bir LQA raporuyla, hata tipine göre sınıflandırılmış olarak teslim edilir.
05. Ücretlendirme nasıl çalışıyor?
Yazılım yerelleştirmesinde tek bir fiyat birimi yok; çünkü iş, yalnızca metinden ibaret değil. Genelde üç kalemi ayrı ayrı konuşuruz.
Çeviri, kaynak kelime üzerinden hesaplanır; TM eşleşme oranı (100% match, fuzzy, no-match) fiyatı doğrudan etkiler. Daha önce çevrilmiş cümlelerin tam eşleşmeleri sıfıra yakın ücretlendirilir, bu yüzden TM'i baştan kurmak orta vadede tasarruf yaratır.
Mühendislik ve LQA saatlik çalışır: dosya hazırlığı, format dönüşümü, placeholder denetimi, test cihazında LQA turu bu kalemde yer alır. Küçük projelerde tek bir paket fiyatına gömülür, büyük projelerde ayrı raporlanır.
Proje yönetimi ise aylık paket veya sürekli akış modellerinde sabit bir yönetim ücreti olarak girer; tek seferlik küçük işlerde ayrıca yansıtılmaz. Pilot bir dil ve sınırlı bir kapsamla başlamak, ücret yapısını gerçek veriyle oturtmanın en sağlıklı yoludur — bu nedenle çoğu projede ilk turu bilinçli olarak küçük tutarız.
06. Hangi dillerde ve pazarlarda çalışıyoruz?
Yazılım projelerinde en yoğun çalıştığımız diller İngilizce, Almanca, Fransızca, Arapça, Rusça, İspanyolca ve İtalyanca. Bunların yanında Hollandaca, Lehçe, Çekçe, Romence, Bulgarca, Ukraynaca ve Yunanca'da düzenli proje yürütüyoruz; uzak Asya tarafında Çince (Basitleştirilmiş), Japonca ve Korece için sektörel deneyim mevcut.
Dil seçimi sadece çevirmen bulmakla ilgili değil; pazar bilgisi de gerekiyor. Almanya için kullanılan Almanca ile Avusturya için kullanılan Almanca arasında küçük ama gerçek farklar var; Latin Amerika İspanyolcası ile İberya İspanyolcası ayrı locale gibi davranılmalı. Arapça veya İbranice eklendiğinde RTL desteğinin uygulama tarafında hazır olup olmadığını birlikte kontrol ederiz; çince ve japonca için satır yüksekliği ve font seçimi de UX'in parçası olur.
Hangi pazarı hedeflediğinizi paylaşırsanız, hangi locale kodunu (`de-DE` vs `de-AT`, `es-ES` vs `es-MX`) seçeceğimizi ve hangi bölgesel uyarlamaların gerekeceğini birlikte belirleriz.