Bence, Geçen hafta bir lojistik firmasının BT direktörüyle Teams üzerinden konuşuyorduk. Adam yarı şaka yarı ciddi dedi — en azından ben öyle düşünüyorum — ki: “Aşkın, bizim Almanya operasyonu her ay 4000 sayfa taranmış irsaliye gönderiyor. Birileri oturup bunları Türkçe’ye çeviriyor. Bunu otomatikleştiremez mıyız?” O an kafamda Build 2026’da Azure Translator tarafında duyurulan yenilikler dönmeye başladı (buna dikkat edin). Çünkü Microsoft, Document Translation servisini tam da bu tıp dertler için yeniden toparlıyor gıbı duruyor.
Bakın, Build 2026’da Foundry Tools altındaki Azure Translator için bayağı dolu bir güncelleme paketi geldi. Açık konuşayım: bazı kısımlar zaten beklediğim şeylerdi, bazıları işe “hmm, bunu da mı eklemişler” dedirtti. Hele görsel çeviri kısmı var ya — kağıt üstünde bakınca “idare eder” diyorsunuz, ama bir POC kurup denediğinizde işin tonu değişiyor, çünkü metni sadece çevirmiyor, ekran görüntüsü. Belge akışına da baya dokunuyor.
Küçük bir detay: Şimdi tek tek bakalım; ne değişmiş, sahada ne iş görüyor, Türkiye’deki kurumlar bunu nereye koyar. Evet.
Görsel Çeviri Artık Senkron Çalışıyor (GA)
Yeni özelliklerin içinde beni en çok heyecanlandıran bu öldü, açık konuşayım. Document Translation API’ye artık doğrudan bir — en azından ben öyle düşünüyorum — .jpg ya da .png dosyası gönderebiliyorsunuz; servis önce gorselin içindeki metni Azure AI Vision ile çekiyor, sonra Translator ile çeviriyor, en sonda da aynı görseli çevrilmiş metinle size geri yolluyor. Layout korunuyor. Hem de senkron çalışıyor — yanı işte çağrıyı atıyorsunuz, cevabı bekliyorsunuz, bitti.
Peki neden bu kadar is görüyor? Bir düşünün. Müşteri hizmetleri ekibiniz Alman bir müşterinin attığı ekran görüntüsünü inceliyor; eskiden ya OCR + manuel kopyala-yapistir + Google Translate üçlüsüne abanıyordunuz, ya da tüm akışı kendiniz kuruyordunuz (Vision çağır, sonucu parse et, Translator’a yolla, sonra goruleri yeniden yerleştir). Bu yeni şey olayı tek API çağrısına indiriyor.
Kısa bir not düşeyim buraya.
Hızlı bir Python örneği vereyim:
import requests
from pathlib import Path
endpoint = "https://<resource>.cognitiveservices.azure.com"
key = "<key>"
img_path = Path("./irsaliye_de.jpg")
resp = requests.post(
f"{endpoint}/translator/document:translate",
params={
"api-version": "2026-03-01",
"sourceLanguage": "de",
"targetLanguage": "tr",
},
headers={"Ocp-Apim-Subscription-Key": key},
files={"document": (img_path.name, img_path.open("rb"), "application/json")},
timeout=120,
)
resp.raise_for_status()
Path("./irsaliye_tr.jpg").write_bytes(resp.content)
Bir POC’de denedim, ortalama 100-200 KB’lık bir görüntü için 2-4 saniye arasında dönüyor. Tabi bu rakam CDN konumuna, görüntünün karmaşıklığına ve hedef dile göre değişiyor; mesela karmaşık bir tablonun olduğu bir görüntüde bir keresinde 6 saniyeye kadar çıktı. Hmm, biraz uzadı ama öldü yanı.
Sahada Karşılaştığım Ilk Sorun
Bi saniye — Ilk denediğimde el yazısı bir nottaki Türkçe metni Almanca’ya cevirmesini istedim. Sonuç… idare ederdi ama beklediğim kadar parlak değildi. AI Vision el (söylemesi ayıp) yazısında hâlâ %85-90 doğrulukta kalıyor; matbaa başımı bir brosurde işe sonuç gerçekten baya iyi çıktı — hatta neredeyse bir grafik tasarımcı dokunuşu gıbı durdu. Garip ama böyle.
Pratik tavsiyem: El yazısı ağırlıklı içeriği bu servise yollamadan önce büyük ihtimalle örneklem üstünde test edin. Matbaa metinler, ekran görüntüleri, ürün etiketleri — bunlarda servis fena hâlde başarılı. El yazısı ve eski taramalarda işe beklentinizi biraz aşağı çekin.
Batch/Asenkron Görsel Çeviri (GA)
Senkron API fena değil, ama gel gör ki gerçek hayatta kim 4000 dosyayı tek tek göndermek ister? Işte burada batch tarafı devreye giriyor. Gorsellerinizi bir Azure Blob Storage container’ına atıyorsunuz, batch API’yi çağırıyorsunuz, servis de bunları sırayla işleyip hedef container’a yazıyor.
Bu is, özellikle su senaryolarda baya işe yarıyor:
- Taranmış arsivlerin toplu dijitallestirilmesi (banka dosyaları, sigorta poliçeleri, tapu evraki)
- Ürün katalog görsellerinin lokalizasyonu — e-ticaret tarafında açıkçası çok anlamlı duruyor
- Eğitim veri setlerinin çoklu dile genişletilmesi (özellikle CV modelleri egitenler için)
- Kullanıcı tarafından yüklenen ekran görüntülerinin asenkron işlenmesi — bunu es geçmeyin
Kendi deneyimimden konuşuyorum, Logosoft’ta bir bankacılık projesinde buna benzer bir akış kurmuştuk 2023 sonunda. Function App, Vision, Translator, Blob Storage ve arada koşan bir sürü retry logic… Şimdi aynı şeyin tek API çağrısına inmiş olmasını görünce insan hem seviniyor hem de hafif burkuluyor; geçen sene harcadigim o haftalara uzulmedim desem yalan ölür — valla güzel iş çıkarmışlar —. Evet.
LLM-Powered Translation: Klasik NMT’den Bir Adım Öte
Bir diğer hayatı yenilik de şu: çeviriyi artık isterseniz büyük dil modellerine, yanı LLM tarafına bırakabiliyorsunuz. Klasik Neural Machine Translation (NMT) kısa ve düz cümlelerde fena iş çıkarmıyor, hatta bazen bayağı iyi gidiyor; ama uzun, bağlamı böl, deyimle dolu metinlerde bir yerde tökezliyor, sonra da toparlamaya çalışırken biraz dağılıyor.
Bak şimdi, bir pazarlama broşürü düşünün. “Çözümümüz, müşterinizin gönlüne dokunur.” gıbı bir cümle var diyelim. NMT bunu çoğu zaman kelime kelime çeviriyor: “Our solution touches your customer’s heart.” Teknik olarak bakınca yanlış değil, ama şey… tadı yok. LLM-tabanlı çeviri işe burada daha doğal bir yere kayıp “Our solution resonates with your customers.” gıbı bir sonuç verebiliyor;. Anlam duruyor, ton da daha oturaklı geliyor (ki bu çoğu kişinin gözünden kaçıyor)
NMT mi, LLM mi? Hangisini Seçeceksiniz?
Bu sorunun tek cevabı yok, açık konuşayım. Senaryoya göre değişiyor; hatta bazen aynı kurum içinde iki yaklaşım da yan yana yürüyebiliyor. Aşağıya hızlı bir tablo koydum:
| Senaryo | NMT | LLM |
|---|---|---|
| Teknik dokümantasyon | ✅ Çok iyi | İyi ama gereksiz pahalı |
| Pazarlama içeriği | Yetersiz | ✅ Belirgin fark |
| Hukukî metinler | İyi | ✅ Bağlam daha iyi yakalanıyor |
| Yüksek hacimli, basit metin | ✅ Maliyet/performans kralı | Aşırı kaçar |
| Edebî içerik, blog yazıları | Düz tat verir | ✅ Net üstün |
Türkiye’deki kurumlara bakınca ben en mantıklı yolun hibrit yaklaşım olduğunu düşünüyorum; ama durun, bu lafı biraz açayım. Yüksek hacimli iç dokümantasyonu (KB makaleleri, ürün kılavuzları) NMT ile çevirmek gayet iş görüyor, müşteri tarafına giden. Marka tonunun önemli (söylemesi ayıp) olduğu içerikte işe LLM devreye alınca sonuç daha doğal geliyor. İlginç, değil mi? Böylece maliyet çok şişmiyor, kalite de elde kalmıyor.
Evet.
Genişletilmiş Yapısal İçerik Desteği
Build duyurularında biraz kenarda kalmış bir detay var, ama ben açık konuşayım, en işe yarar yeniliklerden biri bu. JSON, XML, HTML gıbı yapısal formatlarda çeviri yapılırken iskelet korunuyor; yanı etiketleri, JSON anahtarları, XML attribute’ları olduğu gıbı duruyor, sadece çevrilecek metin parçaları işleniyor. Güzel tarafı bu.
Bu özellikle lokalizasyon işiyle uğraşan ekiplerin elini baya rahatlatıyor. Siz hiç denediniz mi? SPFx 1.23 GA Çıktı: SharePoint Geliştiriciye Mayıs Notları yazımda da değinmiştim — SharePoint web part’larında resource string’lerini farklı dillere ayırmak hep uğraştırıyordu, şimdi işe JSON resource file’ını doğrudan API’ye gönderebiliyorsunuz (evet, bu küçük gıbı duran şey bazen bütün akışı değiştiriyor).
"translate": "no" gıbı marker’lar destekleniyor. Bu da ürün isimleri, kod blokları ve teknik tanımlar için kritik.
Maliyet Tarafı: TL Bazında Ne Anlama Geliyor?
Şimdi herkesin biraz çekindiği o soruya gelelim: bu işin faturası ne? Azure Translator fiyatı karakter üzerinden gidiyor; yanı olay sayfa değil, karakter sayıyor (evet, doğru duydunuz). Standart NMT tarafında 1 milyon karakter çeviri kabaca 10 USD civarında dönüyor, LLM tarafında işe rakam biraz zıplıyor — kullanılan modele göre 2-5 katına çıkabiliyor,. Burada işin rengi değişiyor.
Peki neden?
Doğrusu, Görsel çeviride durum biraz daha karışık (buna dikkat edin). Hem AI Vision için OCR ücreti ödüyorsunuz, hem de Translator için karakter ücreti çıkıyor; bir banka müşterisi için yaptığım kaba hesapta, ayda 10.000 sayfa taranmış belge için (sayfa başına ortalama ~500 karakter varsayarak) toplam maliyet 90-120 USD bandına oturmuştu. Bugünkü kurla bakınca bu da ayda yaklaşık 4000-5000 TL gıbı bir bütçeye denk geliyor, fena değil ama küçük de sayılmaz.
Bunu manuel çeviri ekibiyle yan yana koyunca aradaki fark baya açılıyor. Evet.
Tabi burada kaliteyi de kenara atamıyoruz; hukukî ya da regülasyon ağırlıklı dokümanlarda insan editör hâlâ lazım, çünkü makine bazen metni çeviriyor ama niyeti tam yakalayamıyor. Siz ne dersiniz? Ben açık konuşayım, maliyet düşük diye her şeyi otomatiğe bağlamak bana pek akıllıca gelmiyor.
Türkiye’deki Kurumlar İçin Pratik Uygulama Rehberi
Ne yalan söyleyeyim, Kurumsal müşterilerimde şunu net görüyorum: Türkiye’de bu iş biraz başka akıyor. Çünkü çoğu kurum hâlâ Türkçe ile İngilizce arasında gidip geliyor, yanı işin omurgası iki dilde dönüyor; ama asıl fayda, çok dilli senaryoya girince ortaya çıkıyor, orada tablo bir anda değişiyor.
Çok konuştum, örnekle göstereyim.
- İlk hafta: Bir Azure Translator resource oluşturun, S1 tier’da başlayın. Free tier (F0) test için yetiyor, evet, ama prod’a çıkınca upgrade tarafını es geçemezsiniz.
- İkinci hafta: Çevireceğiniz içerik tipini sınıflandırın. PDF mi, görsel mi, JSON mu? Hangı format baskınsa, API seçimini de o belirliyor; basit gıbı duruyor ama değil.
- Üçüncü hafta: Pilot bir akış kurun. Function App ya da Logic App ile Blob Storage trigger’ını bağlayın, gelen dosyayı Translator’a gönderin; ilk denemede ufak pürüzler çıkarsa şaşırmayın, normaldir.
- Dördüncü hafta: Glossary (terminoloji sözlüğü) ekleyin. Markanıza özel terimlerin, ürün isimlerinin ve sloganların sabit çevrilmesini sağlar; bunu atlamayın çünkü kalite farkı bayağı hissediliyor.
Eh, Eğer bütçeniz sıkışıksa ve hacim düşükse (ayda <100.000 karakter), açık konuşayım Azure Translator yerine OSS modellerle (mesela NLLB) kendi container’ınızda çalışabilirsiniz. Hmm, kulağa ekonomik geliyor tabii. Ama 1M+ karakter bandına çıkınca iş değişiyor; operasyon yükünü de koyunca Azure tarafı daha az uğraştırıyor, yanı kafa rahatlığı burada ciddi artıyor.
Enterprise mi, Startup mı?
Küçük bir ekipseniz doğrudan senkron API ile başlayın. Karmaşıklığa boğulmadan, basit HTTP çağrılarıyla işi yürütmek mümkün; hatta çoğu zaman yeter de artar bile. Büyük kurumsal yapıdaysanız batch API ile Azure Data Factory pipeline’ını birlikte kullanın, çünkü kurumsalda konu bir noktadan sonra çeviriden çıkıp entegrasyona kayıyor (SAP’ye gitsin mi, ServiceNow ticket’ına eklensin mi gıbı sorular hemen kapıyı çalıyor).
Bir dakika — bununla bitmedi.
Bu arada yukarıda bahsettiğim agent yaklaşımı var ya, önü da bununla birleştirebilirsiniz — Foundry’de Agent Dağıtımı: Teams ve M365 Copilot Devri yazımda değindiğim gıbı, bir Foundry agent’ı çeviri orkestrasyonunu üstlenebilir ve Teams üzerinden tetiklenebilir. Kulağa biraz fazla otomasyon gıbı geliyor olabilir ama bazen tam da gereken şey bu oluyor.
Eksik Kalan Yanlar
Bütün bu güzel tarafların yanında, açık konuşayım, eksik kalan şeyler de var. Bir tanesi şu: el yazısı görsel çevirisi hâlâ biraz ham duruyor, yanı iş görüyor ama “tam öldü” dedirtmiyor; ikincisi, video içeriği için native bir endpoint yok, dolayısıyla altyazı çevirisini almak istiyorsanız Speech Services ile Translator’ı kendiniz yan yana kuruyorsunuz, sonra da akışın kırıldığı yerleri tek tek toparlıyorsunuz. Üçüncüsü de daha can sıkıcı: bazı düşük kaynaklı diller, mesela Kürtçe Sorani ya da Türkmence, LLM tarafında hâlâ beklediğiniz seviyeye gelmiş değil.
Bir de şu kısmı atlamayayım. GA dediler ama region availability hâlâ sınırlı kalıyor; West Europe ve East US öne çıkan seçenekler gıbı duruyor. Türkiye açısından en yakın bölge West Europe oluyor, latency tarafında fena değil ama veri rezidanslığı ve KVKK uyumu kafaya takılıyorsa, burada ekstra bir değerlendirme yapmak gerekiyor. Evet.
Sıkça Sorulan Sorular
Azure Document Translation Türkçe karakterleri tam destekliyor mu?
Doğrusu, Evet, Türkçe hem kaynak hem hedef dil olarak gayet iyi çalışıyor (kendi tecrübem). Hem NMT hem LLM tarafında. Yalnız glossary kullanırken dosyalarınızın UTF-8 encode edilmiş olmasına dikkat edin — hani bir keresinde Windows-1254 encoding yüzünden saatlerce uğraşmıştım, açıkçası çok sınır bozucu bir şeydi.
Görsel çeviride orijinal layout çoğu zaman koruluyor mu?
Burada, ne yalan söyleyeyim, Çoğunlukla evet, ama %100 değil. En çok da çevrilen metin orijinalden çok uzunsa — mesela İngilizce’den Almanca’ya çeviride metin %30 falan uzayabiliyor — layout’ta küçük kaymalar görülebiliyor. Bence kritik görsellerde mutlaka örnek üstünde test etmek lazım.
Batch işlemlerde maksimum dosya sayısı sınırı var mı?
Resmî limit container başına 1000 dosya, toplam 250 GB (ciddiyim). Ama pratikte daha büyük setleri parçalamanızı öneririm —. Hem retry yönetimi kolaylaşıyor hem de hata durumunda her şey baştan başlamıyor. Tecrübeme göre bu küçük önlem çok iş kurtarıyor.
LLM-tabanlı çeviri, klasik NMT’yi bayağı ezecek mi?
Hayır, en azından yakın gelecekte böyle bir şey olmayacak. NMT hâlâ maliyet/performans açısından çok güçlü. LLM işe yüksek katma değerli içerikte parlıyor. Aslında — hayır dür, daha doğrusu hibrit kullanım önümüzdeki yıllarda standart hâline gelecek bence.
On-premise veya hava boşluğunda (air-gapped) çalıştırabilir mıyım?
Şu an için Translator’ın container versiyonu sınırlı dil desteğiyle mevcut. Ama LLM-tabanlı çeviri ve görsel çeviri henüz container’a inmedi — bunlar cloud-only. Yanı regülasyonu ağır sektörlerde alternatif mimarı düşünmek gerekiyor.
Kaynaklar ve İleri Okuma
Bir şey dikkatimi çekti:
Microsoft Foundry Blog: Document Translation at Build 2026
Azure Document Translation Resmî Dokümantasyonu
Azure Translator Fiyatlandırma Detayları
(şaşırtıcı ama gerçek)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
