Bu içerik Eylül Çeviri tercüme uzmanları tarafından hazırlanmıştır — 2026 güncel.
Yazılım tercümesi, kullanıcı arayüzü, mobil uygulama, web paneli, API dokümantasyonu, yardım merkezi, hata mesajları ve siber güvenlik metinlerinin hedef dile teknik anlam ve kullanıcı deneyimi korunarak aktarılmasıdır. Bu süreç yalnız kelime çevirisi değildir; metin uzunluğu, değişkenler, kod parçaları, menü hiyerarşisi ve terminoloji birlikte yönetilmelidir.
Yazılım ürünlerinde aynı kelime farklı bağlamlarda tamamen farklı anlam taşıyabilir. “Token”, “session”, “endpoint”, “scope”, “payload”, “patch”, “commit” veya “key” gibi terimler günlük sözlük karşılıklarıyla çevrildiğinde teknik hata oluşabilir. Arayüzde ise karakter sınırı, buton genişliği ve kullanıcı eylemi önem kazanır. API dokümantasyonunda kod bloklarının çevrilmemesi, açıklamaların ise geliştirici terminolojisine uygun aktarılması gerekir.
Bu rehberde şunları öğreneceksiniz: yazılım arayüzü nasıl çevrilir, API dokümantasyonunda hangi alanlar korunur, siber güvenlik terminolojisi nasıl yönetilir, değişken ve placeholder’lar nasıl kontrol edilir, yerelleştirme ile düz çeviri arasındaki fark nedir ve kalite testi nasıl yapılır.
Yazılım Tercümesi ile Yerelleştirme Arasındaki Fark Nedir?
Yazılım tercümesi metni bir dilden başka dile aktarırken yerelleştirme, ürünü hedef pazara dil, tarih, sayı, para birimi, kültürel kullanım ve kullanıcı deneyimi açısından uyarlamayı da kapsar. Bu nedenle localization yalnız çevirinin farklı adı değildir.
Örneğin “MM/DD/YYYY” tarih biçimi Türk kullanıcı için “DD.MM.YYYY” biçimine çevrilebilir. Ondalık ayırıcı, para birimi, adres biçimi, saat sistemi ve telefon numarası gösterimi de hedef pazara göre değişebilir.
Arayüz metni de hedef dilde daha uzun olabilir. İngilizce “Save” butonu Türkçede “Kaydet”, Almancada daha uzun karşılıklarla görünebilir; tasarım bu genişlemeyi taşıyamıyorsa yalnız doğru tercüme yapmak yeterli olmaz.
Eylül Çeviri olarak web sitesi çevirisi ve lokalizasyon projelerinde metni arayüz bağlamıyla birlikte değerlendiriyoruz. Butonun ne yaptığını bilmeden yalnız kelimeyi çevirmek kullanıcı deneyimini bozabilir.
Yerelleştirme aynı zamanda test süreci gerektirir. Çeviri dosyada doğru olsa bile uygulama ekranında kesilebilir veya yanlış menüde görünebilir.
Yerelleştirme sürecinde ayrıca mağaza açıklaması, onboarding ekranı ve destek merkezi gibi ürün çevresindeki içerikler de hedef pazara uyarlanabilir. Bu nedenle proje kapsamı yalnız uygulama içi string dosyasından ibaret olmayabilir.
Yazılım Tercümesi Arayüz Metinlerinde Nasıl Yapılır?
Yazılım tercümesi arayüzde kısa, eylem odaklı ve bağlama uygun ifadeler gerektirir. Buton, menü, bildirim, hata mesajı ve onay ekranı aynı kelimeyi farklı işlevle kullanabilir.
“Close” bir pencereyi kapatma eylemi olabilir; “closed” bir kaydın durumunu gösterebilir. “Delete” ile “Remove” aynı üründe farklı işlevler taşıyabilir. Çevirmen bu farkı kaynak anahtar, ekran görüntüsü veya geliştirici notu olmadan her zaman göremez.
Arayüz çevirisinde karakter sınırı da önemlidir. Mobil ekranda uzun Türkçe karşılık taşabilir; ancak yalnız sığdırmak için anlamı bozacak kısaltma yapılmamalıdır.
teknik tercüme yaklaşımı özellikle hata mesajlarında önemlidir. “Authentication failed”, “connection timed out” veya “permission denied” gibi ifadeler kullanıcıya teknik sorunun doğru türünü anlatmalıdır.
Eylül Çeviri olarak bağlam eksikliği olan string dosyalarında ekran görüntüsü veya geliştirici açıklaması istemeyi tercih ediyoruz. Aynı kaynak kelimenin farklı string ID’lerinde farklı karşılığa ihtiyaç duyabileceği unutulmamalıdır.
Buton ve menü adlarında fiil veya isim kullanımının ürün genelinde tutarlı olması gerekir. Bir ekranda “Ayarlar”, başka ekranda aynı bölüme “Tercihler” denmesi kullanıcıyı gereksiz yere farklı işlev aramaya yöneltebilir.
Yazılım Tercümesi API Dokümantasyonunda Nasıl Yapılır?
Yazılım tercümesi API dokümantasyonunda açıklama metni ile kodun birbirinden ayrılmasını gerektirir. Endpoint URL’si, parametre adı, JSON key, header adı ve örnek kod çoğu zaman çevrilmez; bunları açıklayan metin hedef dile aktarılır.
Örneğin “POST /users”, “Authorization”, “Content-Type”, “user_id” veya “access_token” teknik anahtar olarak korunabilir. Çevirmen bu ifadeleri Türkçeleştirirse geliştirici dokümantasyondaki kodu gerçek sistemle eşleştiremez.
Aşağıdaki tablo temel ayrımı gösterir.
Tablo: API dokümantasyonunda çevrilen ve korunan alanlar
| Alan | Yaklaşım | Örnek |
|---|---|---|
| Endpoint | Genellikle korunur | POST /users |
| JSON key | Korunur | user_id |
| Açıklama metni | Çevrilir | Parametrenin ne yaptığı |
| Hata açıklaması | Bağlama göre çevrilir | Yetki veya bağlantı açıklaması |
| Kod örneği | Kod korunur, yorum gerekirse çevrilebilir | curl, Python, JavaScript örneği |
API dokümanında teknik terimlerin geliştirici topluluğundaki yerleşik kullanımına dikkat edilmelidir. Her İngilizce kelimeyi zorla Türkçeleştirmek dokümanı daha anlaşılır hale getirmeyebilir.
Kod blokları çevrilmese de örnek açıklamalarda kullanılan sahte kullanıcı adı, tarih veya veri biçimi hedef pazara göre uyarlanabilir. Bu tür değişiklikler teknik anahtarları bozmadan yapılmalıdır.
Ayrıca bağlantı, kod bloğu ve örnek istek-cevap yapısının hedef dosyada bozulmadığı kontrol edilmelidir.
Yazılım Tercümesi Değişken ve Placeholder’larda Nasıl Kontrol Edilir?
Yazılım tercümesi sırasında değişken, placeholder ve markup işaretlerinin bozulmaması gerekir. “%s”, “{name}”, “{{count}}”, “%1$d” veya HTML etiketleri yanlış değiştirilirse uygulama hata verebilir.
Çevirmen değişkeni çevirmemeli, ancak değişkenin cümledeki yerini hedef dilin sözdizimine göre değiştirebilir. Örneğin “Welcome, {name}” ifadesi “Hoş geldiniz, {name}” şeklinde çevrilebilir; değişkenin süslü parantezleri korunur.
Çoğul yapılar da dile göre değişebilir. İngilizcede tekil ve çoğul iki form yeterli olabilirken başka diller daha fazla plural form kullanabilir. Çeviri platformu ICU MessageFormat veya benzeri yapı kullanıyorsa bu kurallar dikkate alınmalıdır.
Yazılım dosyalarında teknik token’ları metinden ayrı kontrol etmek, değişken ve placeholder hatalarını azaltır. Çevirmen tarafından yanlışlıkla silinen yüzde işareti veya parantez üretim ortamında doğrudan hata yaratabilir.
QA araçları placeholder sayısını kaynak ve hedef arasında karşılaştırabilir. Bu otomatik kontrol insan dil revizyonuna ek güvenlik katmanı sağlar.
Çeviri platformunda kilitli token veya tag koruma özelliği varsa etkinleştirilmesi hata riskini azaltır. Yine de otomatik koruma tek başına yeterli değildir; cümlenin hedef dilde doğal sırada kaldığı da kontrol edilmelidir.
Yazılım Tercümesi Siber Güvenlik Metinlerinde Neden Özeldir?
Yazılım tercümesi siber güvenlik alanında tehdit, açık, kimlik doğrulama ve erişim kontrolü gibi özel terminoloji içerir. “Vulnerability”, “exploit”, “phishing”, “credential”, “privilege escalation”, “zero-day” veya “multi-factor authentication” gibi terimler bağlama göre yerleşik karşılıkla kullanılmalıdır.
Siber güvenlik metninde küçük anlam farkı kullanıcı davranışını etkileyebilir. “Reset your password” ile “change your password”, “revoke token” ile “delete token” veya “suspend account” ile “close account” aynı işlem değildir.
Ürün güvenlik bültenlerinde CVE numarası, sürüm numarası ve yama bilgileri çevrilmez; açıklama metni doğru teknik anlamla aktarılır. Bir güvenlik açığının hangi sürümleri etkilediği yanlış yazılırsa kullanıcı gereksiz veya eksik güncelleme yapabilir.
ticari kurumsal tercüme ile güvenlik iletişimi bir araya geldiğinde marka dili kadar teknik doğruluk da korunmalıdır.
Gizli güvenlik açığı bilgileri çeviri için üçüncü taraf sistemlere yüklenmeden önce şirketin veri güvenliği politikası kontrol edilmelidir.
Güvenlik bildirimlerinde eylem fiilleri özellikle nettir. Kullanıcının oturumu kapatması, parolayı değiştirmesi veya erişim anahtarını iptal etmesi gerekiyorsa çeviri bu işlemleri birbirinden ayırmalıdır.
Özellikle güvenlik uyarılarında kullanıcıdan istenen eylem açık, kısa ve teknik olarak doğru kalmalıdır.
Yazılım Tercümesi Terminolojisi Nasıl Yönetilir?
Yazılım tercümesi terminolojisi ürün genelinde tek bir kaynakta yönetilmelidir. Kullanıcı arayüzü, yardım merkezi, API dokümanı ve pazarlama sitesi aynı özellik için farklı ad kullanırsa kullanıcı deneyimi parçalanır.
Terim listesinde ürün özelliği, menü adı, teknik terim, kullanılmaması gereken karşılık ve açıklama bulunabilir. Çevirmen yeni terimle karşılaştığında önce mevcut glossary’yi kontrol eder.
Sürüm yönetimi de önemlidir. Ürün “Workspace” özelliğini daha sonra “Project Space” olarak yeniden adlandırdıysa eski çeviriler otomatik kopyalanmamalıdır.
Eylül Çeviri olarak düzenli yazılım projelerinde onaylı terminoloji ile çeviri belleğini birlikte kullanıyoruz. Böylece yeni sürümlerde tekrar eden string’ler daha tutarlı yönetilebilir.
Terminoloji kararı yalnız çevirmenin tercihi olmamalıdır. Ürün, pazarlama ve teknik ekiplerin onayı gereken kavramlar proje yöneticisi üzerinden sabitlenebilir.
Glossary güncellendiğinde eski ekranların da yeni terimle uyumlu olup olmadığı kontrol edilebilir. Aksi halde yeni sürümde aynı özellik farklı menülerde iki ayrı adla görünebilir.
Terim listesine geliştirici ekibinin onay tarihi de eklenirse sonraki sürümlerde hangi karşılığın geçerli olduğu daha kolay izlenebilir.
Sürüm notları da bu terminolojiyle uyumlu tutulmalıdır.
Yazılım Tercümesi Yapay Zeka ile Yapılabilir mi?
Yazılım tercümesi yapay zeka ile büyük string dosyalarında ilk taslak ve terim önerisi için hızlandırılabilir. Ancak bağlamı olmayan kısa string’lerde yapay zeka da insan gibi yanlış anlam seçebilir.
“Open”, “Save”, “Run”, “Build”, “Commit” veya “Issue” gibi tek kelimelik string’lerin teknik bağlamı bilinmeden doğru çevrilmesi zordur. Yapay zeka ekranı veya fonksiyonu görmüyorsa akıcı ama yanlış karşılık verebilir.
Kod parçaları ve gizli API bilgileri de ayrı risk taşır. Üretim anahtarı, erişim token’ı veya yayımlanmamış güvenlik bilgisi üçüncü taraf sisteme yüklenmemelidir.
Yapay zeka kullanılsa bile placeholder, HTML etiketi, link, ürün adı ve teknik anahtarlar otomatik QA ile kontrol edilmelidir. Nihai ekran testi insan tarafından yapılmalıdır.
Profesyonel iş akışında yapay zeka yardımcı araç olabilir; ürün bağlamını ve kullanıcı deneyimini tek başına yönetmez.
Yapay zeka çıktısı özellikle kısa string’lerde güven skoru yüksek görünse bile bağlam hatası yapabilir. Ekran görüntüsü ve string açıklaması sağlamak hem insan hem otomatik sistem için doğruluğu artırır.
Otomatik çıktının ürün adlarını veya kod öğelerini yanlışlıkla çevirmediği de ayrıca denetlenmelidir.
Yazılım Tercümesi Kalite Testi Nasıl Yapılır?
Yazılım tercümesi kalite testi dosya üzerinde ve gerçek ürün içinde iki aşamada yapılabilir. Dosya QA’sı terminoloji ve token hatalarını bulurken in-context test metnin ekranda nasıl göründüğünü gösterir.
- Terminolojiyi kontrol edin. Menü ve özellik adlarını glossary ile karşılaştırın.
- Placeholder’ları doğrulayın. Kaynak ve hedefte değişken sayısını eşleştirin.
- Kod parçalarını koruyun. Endpoint, key ve teknik anahtarları değiştirmeyin.
- Karakter taşmasını test edin. Mobil ve masaüstü ekranları ayrı inceleyin.
- Hata mesajlarını deneyin. Gerçek kullanıcı eylemiyle doğru mesajın çıktığını doğrulayın.
- Yerel biçimleri kontrol edin. Tarih, saat, sayı ve para birimini hedef pazara göre test edin.
Son kalite turunda çeviri ekibi ile ürün veya QA ekibinin birlikte çalışması yararlıdır. Dilsel olarak doğru string’in yanlış ekrana bağlanması yalnız ürün içinde görülebilir.
Yerelleştirme testi farklı ekran boyutları ve işletim sistemi sürümlerinde tekrarlanabilir. Aynı metin masaüstünde düzgün görünürken küçük telefon ekranında taşabilir.
Gerçek cihaz testi, dosya üzerinde fark edilmeyen satır sonu ve buton genişliği sorunlarını ortaya çıkarabilir.
Test sonuçları geliştirici ekiple paylaşılmalıdır.
Sıkça Sorulan Sorular
Yazılım tercümesi ile lokalizasyon aynı şey mi?
Hayır, yazılım tercümesi metnin dilini değiştirirken lokalizasyon tarih, sayı, para birimi, kültürel kullanım ve arayüz uyumu gibi daha geniş adaptasyonları da kapsar.
Bir ürün doğru çevrilmiş olsa bile hedef pazara teknik ve kültürel olarak uyarlanmamış olabilir.
Hayır, lokalizasyon ürün deneyimini hedef pazara uyarlar ve yalnız metin çevirisinden daha geniş teknik ve kültürel kontroller içerir.
API dokümantasyonunda kod çevrilir mi?
Hayır, endpoint, JSON key, parametre adı ve örnek kod çoğu durumda çevrilmez. Bu alanları açıklayan metin hedef dile aktarılır.
Kod içindeki kullanıcıya gösterilen string veya yorum satırı ayrıca proje kuralına göre çevrilebilir.
Hayır, kodun çalışmasını etkileyen anahtar ve syntax unsurları korunmalıdır; yalnız açıklama ve gerektiğinde yorum metinleri çevrilir.
Hayır, kod yapısı ve teknik anahtarlar değiştirilirse örneklerin çalışması veya geliştirici tarafından anlaşılması bozulabilir.
Yazılım tercümesinde placeholder değiştirilebilir mi?
Hayır, placeholder’ın yapısı değiştirilmemelidir. “{name}” veya “%s” gibi teknik öğeler korunur; yalnız cümle içindeki konumu hedef dil sözdizimine göre değişebilir.
Kaynak ve hedef placeholder sayısı QA aracıyla karşılaştırılmalıdır.
Hayır, placeholder adı ve işaretleri korunur; yalnız hedef dil cümlesindeki yeri gerektiğinde değiştirilebilir.
Hayır, placeholder biçimi uygulamanın çalışma mantığının parçasıdır ve kaynakla aynı teknik yapı korunmalıdır.
Siber güvenlik metinleri normal yazılım tercümesinden farklı mı?
Evet, siber güvenlik metinleri tehdit, kimlik doğrulama, açık ve erişim kontrolü gibi özel terminoloji içerir. CVE numarası, sürüm ve güvenlik etkisi gibi veriler özellikle dikkat ister.
Gizli güvenlik bilgileri ayrıca veri koruma politikasıyla yönetilmelidir.
Evet, güvenlik terminolojisi ve eylem talimatları yanlış anlaşılırsa kullanıcı yanlış güvenlik adımı uygulayabilir.
Evet, yanlış terim kullanımı kullanıcının güvenlik olayına hatalı tepki vermesine veya yanlış işlemi uygulamasına neden olabilir.
Yazılım tercümesinde yapay zeka kullanılabilir mi?
Evet, ilk taslak ve terminoloji önerisinde kullanılabilir. Ancak kısa bağlamsız string’ler, teknik token’lar ve ekran yerleşimi insan tarafından kontrol edilmelidir.
Üretim anahtarı veya gizli güvenlik verisi üçüncü taraf sisteme yüklenmemelidir.
Evet, ancak kod, token, bağlam ve terminoloji kontrolleri otomatik çıktıdan sonra mutlaka insan ve QA araçlarıyla yapılmalıdır.
Evet, ancak ürün bağlamı, kod öğeleri, gizlilik ve terminoloji son kontrolde insan uzman tarafından yeniden doğrulanmalıdır.
