Mevcut bir iş uygulamasında çeviri entegrasyonunun kapsamı nasıl belirlenir?
İş uygulamanızda çeviriyi planlayın. Teklif istemeden önce içeriği, dilleri, incelemeyi, veri kurallarını, hata yönetimini ve kabul testlerini tanımlayın.
Ekibinizin başka bir dilde yapması gereken eksiksiz bir görevle başlayın. Ardından çevirinin bu göreve nasıl yerleşeceğini tanımlayın. Bu, bir yazılım tedarikçisine maliyet tahmini için "bir çeviri düğmesi ekleyin" talebinden daha net bir temel sunar.
Kapsam metni, kişileri, verileri ve sonucu içermelidir. Çeviri başarısız olduğunda ne olacağını da açıklamalıdır. Teknik bir yaklaşım seçmeden önce bu kapsamı hazırlamak için aşağıdaki adımları kullanın.
İlk sürüm için tek bir iş akışı seçin
Kaynak metnin nereden geldiğini ve onaylanan çevirinin nereye gitmesi gerektiğini yazın. Örneğin bir destek çalışanının gelen bir mesajı okuması ve müşterinin dilinde bir yanıt hazırlaması gerekebilir. Bu, açıklayıcı bir gereksinimdir; bir Vavus kurulumunun raporu değildir.
Her adımı listeleyin: mesajı açma, çeviri isteme, kaynak metni sonucun yanında okuma, yanıtı düzenleme ve gönderilmesini onaylama. Çevirinin otomatik olarak mı, yoksa yalnızca bir çalışan seçtikten sonra mı başlayacağına karar verin.
İlk sürümü küçük tutun. Tek bir ekranı ve tek bir net iş görevini test etmek, bir uygulamadaki her metin alanını test etmekten daha kolaydır.
İçerik ve dil ihtiyaçlarını belirleyin
Çeviri gerektiren alanların listesini çıkarın. Kısa etiketleri, serbest metni, belgeleri ve konuşmayı birbirinden ayırın. Bunlar farklı işleme ve testler gerektirebilir. Sipariş numaraları ve ürün kodları gibi değişmeden kalması gereken alanları da listeleyin.
Bölgesel varyantlar dahil kaynak ve hedef dilleri belirtin. Tipik metin uzunluğunu ve beklenen günlük hacmi kaydedin. Önerilen hizmetin hangi dil kombinasyonlarını ve girdi biçimlerini desteklediğini sorun.
Kısa metinlerde bağlam önemli olabilir. Örneğin DeepL'in metin API'si, bağlamın kendisini çevirmeden çeviriyi etkileyebilen bir bağlam parametresini destekler. Belgelerinde ayrıca tek bir istekteki ayrı metin girdilerinin bağlamı paylaşmadığı belirtilir. [1] Kapsamınızda yararlı bağlamın nereden geleceği yazmalıdır.
Terminolojiyi ve insan incelemesini tanımlayın
İşletmenizin sık kullandığı terimleri toplayın. Tercih edilen çevirileri, ürün adlarını ve değişmeden kalması gereken kelimeleri ekleyin. Bu listenin bakımı için bir kişiyi sorumlu tutun.
Bazı çeviri hizmetleri terim sözlüklerini destekler. Google Cloud Translation, terim sözlüğünü alana özgü terminolojinin tutarlı olması için özel bir sözlük olarak tanımlar. [2] Özelliği tam olarak kullanacağınız dil çiftleri ve seçtiğiniz hizmet için kontrol edin. Terim sözlüğü, mesajın tamamının doğru olduğunu kanıtlamaz.
Hangi çıktıların nitelikli bir dil denetçisi gerektirdiğine karar verin. Denetçiye orijinal metne erişim verin. Müşteriye yönelik metin gönderilmeden veya yayımlanmadan önce net bir onay adımı belirleyin.
Veri ve erişim kurallarını belirleyin
İş akışının hangi bilgileri işlediğini açıklayın. İlk testlerde yapay örnekler kullanın. Sırf bir düğmenin çalışıp çalışmadığını görmek için gerçek müşteri kayıtlarını bir denemeye kopyalamayın.
Metnin nerede işleneceğini, uygulamanın neleri saklayacağını, kimlerin okuyabileceğini ve ne zaman silineceğini sorun. Kayıt dosyalarını ve yedekleri de bu görüşmeye dahil edin. Sağlayıcının güncel koşullarını ve seçilen plan için mevcut denetimleri teyit edin.
Özel bir arayüz, harici bir çeviri hizmetini tek başına gizli veya çevrimdışı hâle getirmez. Projeniz yerel işleme gerektiriyorsa bu gereksinimi en başta belirtin ve veri akışının tamamını buna göre test edin.
Gecikmeler ve hatalar için plan yapın
Beklenen yanıt süresini ve hizmet kullanılamadığında personelin ne yapması gerektiğini yazın. Uygulama "bekliyor", "incelemeye hazır" veya "başarısız" gibi net bir durum göstermelidir. Orijinal metni koruyun.
Geliştiriciden geçici hataları, değişiklik gerektiren hatalardan ayırmasını isteyin. Örneğin DeepL, istek sınırı hataları için bekleyerek yeniden denemeyi belgeler; kotanın dolması ise farklı bir yanıt gerektirir. [3] Tekrarlanan istekler, aynı yanıtın iki kez gönderilmesi gibi yinelenen iş işlemlerine yol açmamalıdır.
Kullanım uyarıları ve desteğin kimin sorumluluğunda olacağı konusunda anlaşın. Proje maliyetlerini karşılaştırırken hizmet ücretlerini, bakımı ve ileride yapılacak değişiklikleri de hesaba katın.
Geliştirmeden önce kabul testlerini yazın
Gerekli her dil çifti için temsili örnekler seçin. Uzun mesajlar, alışılmadık karakterler, eksik alanlar ve onaylı listenizdeki terimler ekleyin. Görevin tamamını, kaynak kayıttan kaydedilen veya gönderilen sonuca kadar test edin.
İnsanların kontrol edebileceği geçme ölçütleri belirleyin: Ürün kodları değişmez, onaylanmamış bir çeviri gönderilemez, başarısız bir istek görünür olur ve denetçi kaynağa geri dönebilir. Anlamı ve üslubu nitelikli bir denetçiye değerlendirtin. Kusurları kaydedin ve değişikliklerden sonra aynı testleri tekrarlayın.
Net bir teklif talebi hazırlayın
İş akışını, örnek alanları, dil çiftlerini, tahmini hacmi, veri kurallarını ve kabul testlerini gönderin. Her maddeyi lansman için zorunlu veya sonraki bir sürüme uygun olarak işaretleyin. Varsayımların ve kapsam dışı işlerin yazılı olarak bildirilmesini isteyin.
Vavus, özel projeler için yazılı kapsam belirleme sunar. [4] Mevcut uygulamanızı ve iyileştirmek istediğiniz görevi anlatmak için teklif sayfasını kullanın. Önerilen entegrasyon, kurulum ve testler proje kapsamınızda teyit edilmelidir.