Cara menyusun ruang lingkup integrasi terjemahan untuk aplikasi bisnis yang sudah ada
Rencanakan terjemahan di aplikasi bisnis Anda. Tentukan konten, bahasa, peninjauan, aturan data, penanganan kegagalan, dan uji penerimaan sebelum meminta penawaran.
Mulailah dengan satu tugas lengkap yang perlu dikerjakan tim Anda dalam bahasa lain. Kemudian tentukan bagaimana terjemahan masuk ke dalam tugas itu. Dengan begitu, pemasok perangkat lunak mendapat dasar perkiraan yang lebih jelas daripada sekadar permintaan untuk menambahkan tombol terjemahan.
Ruang lingkupnya harus mencakup teks, orang, data, dan hasilnya. Ruang lingkup itu juga harus menjelaskan apa yang terjadi ketika terjemahan gagal. Gunakan langkah-langkah di bawah ini untuk menyiapkan ruang lingkup tersebut sebelum Anda memilih pendekatan teknis.
Pilih satu alur kerja untuk rilis pertama
Tuliskan dari mana teks sumber berasal dan ke mana terjemahan yang disetujui harus dikirim. Misalnya, seorang staf dukungan mungkin perlu membaca pesan masuk dan menyiapkan balasan dalam bahasa pelanggan. Ini adalah contoh persyaratan ilustratif, bukan laporan tentang instalasi Vavus.
Daftarkan setiap langkah: membuka pesan, meminta terjemahan, membaca sumber di samping hasilnya, menyunting balasan, dan menyetujuinya untuk dikirim. Tentukan apakah terjemahan dimulai secara otomatis atau hanya setelah karyawan memilihnya.
Buat rilis pertama tetap kecil. Satu layar dan satu tugas bisnis yang jelas lebih mudah diuji daripada setiap kolom teks di sebuah aplikasi.
Identifikasi kebutuhan konten dan bahasa
Buat daftar kolom yang perlu diterjemahkan. Pisahkan label pendek, teks bebas, dokumen, dan ucapan. Masing-masing dapat memerlukan pemrosesan dan pengujian yang berbeda. Daftarkan juga kolom yang tidak boleh berubah, seperti nomor pesanan dan kode produk.
Tentukan bahasa sumber dan bahasa target, termasuk varian regionalnya. Catat panjang teks yang umum dan perkiraan volume harian. Tanyakan kombinasi bahasa dan format input apa saja yang didukung oleh layanan yang diusulkan.
Konteks bisa penting untuk teks pendek. API teks DeepL, misalnya, mendukung parameter context yang dapat memengaruhi terjemahan tanpa menerjemahkan konteks itu sendiri. Dokumentasinya juga menyebutkan bahwa entri teks yang terpisah dalam satu permintaan tidak berbagi konteks. [1] Ruang lingkup Anda harus menyebutkan dari mana konteks yang berguna berasal.
Tentukan terminologi dan peninjauan oleh manusia
Kumpulkan istilah yang sering digunakan bisnis Anda. Sertakan terjemahan yang diutamakan, nama produk, dan kata-kata yang harus tetap tidak diubah. Tunjuk satu orang untuk mengelola daftar ini.
Beberapa layanan terjemahan mendukung glosarium. Google Cloud Translation menggambarkan glosariumnya sebagai kamus khusus untuk terminologi bidang tertentu yang konsisten. [2] Periksa fitur ini untuk pasangan bahasa Anda yang sebenarnya dan layanan yang Anda pilih. Glosarium tidak membuktikan bahwa seluruh pesan sudah benar.
Tentukan hasil mana yang memerlukan peninjau bahasa yang kompeten. Berikan peninjau akses ke teks asli. Tetapkan langkah persetujuan yang jelas sebelum teks untuk pelanggan dikirim atau diterbitkan.
Tetapkan aturan untuk data dan akses
Jelaskan informasi apa yang ditangani alur kerja ini. Gunakan contoh buatan selama pengujian awal. Hindari menyalin data pelanggan sungguhan ke dalam uji coba hanya untuk melihat apakah sebuah tombol berfungsi.
Tanyakan di mana teks akan diproses, apa yang akan disimpan aplikasi, siapa yang dapat membacanya, dan kapan teks itu akan dihapus. Sertakan log dan cadangan dalam pembahasan ini. Pastikan ketentuan penyedia yang berlaku saat ini dan kontrol yang tersedia untuk paket yang dipilih.
Antarmuka kustom tidak dengan sendirinya membuat layanan terjemahan eksternal menjadi privat atau dapat digunakan offline. Jika proyek Anda memerlukan pemrosesan lokal, nyatakan persyaratan itu sejak awal dan uji seluruh aliran data terhadapnya.
Rencanakan penanganan keterlambatan dan kesalahan
Tuliskan waktu respons yang diharapkan dan tindakan yang harus diambil staf jika layanan tidak tersedia. Aplikasi harus menampilkan status yang jelas, seperti menunggu, siap ditinjau, atau gagal. Pertahankan teks aslinya.
Minta pengembang untuk membedakan kegagalan sementara dari kesalahan yang memerlukan perubahan. DeepL, misalnya, mendokumentasikan percobaan ulang yang ditunda untuk kesalahan batas laju, sedangkan kuota yang habis memerlukan penanganan yang berbeda. [3] Permintaan yang diulang tidak boleh menimbulkan tindakan bisnis ganda, seperti mengirim balasan yang sama dua kali.
Sepakati peringatan penggunaan dan siapa yang bertanggung jawab atas dukungan. Sertakan biaya layanan, pemeliharaan, dan perubahan di masa mendatang saat Anda membandingkan biaya proyek.
Tulis uji penerimaan sebelum pengembangan
Pilih contoh yang representatif untuk setiap pasangan bahasa yang diperlukan. Sertakan pesan panjang, karakter yang tidak biasa, kolom yang kosong, dan istilah dari daftar yang telah Anda setujui. Uji seluruh tugas, dari catatan sumber hingga hasil yang disimpan atau dikirim.
Tetapkan kriteria lulus yang dapat diperiksa orang: kode produk tetap tidak berubah, terjemahan yang belum disetujui tidak dapat dikirim, permintaan yang gagal terlihat, dan peninjau dapat kembali ke teks sumber. Minta peninjau yang kompeten untuk menilai makna dan nada. Catat kekurangan yang ditemukan dan ulangi pengujian yang sama setelah ada perubahan.
Siapkan permintaan penawaran yang jelas
Kirimkan alur kerja, contoh kolom, pasangan bahasa, perkiraan volume, aturan data, dan uji penerimaan. Tandai setiap butir sebagai wajib untuk peluncuran atau cocok untuk rilis berikutnya. Minta asumsi dan pengecualian secara tertulis.
Vavus menawarkan penyusunan ruang lingkup tertulis untuk proyek kustom. [4] Gunakan halaman penawaran untuk menjelaskan aplikasi Anda yang sudah ada dan tugas yang ingin Anda tingkatkan. Integrasi, penerapan, dan pengujian yang diusulkan harus dikonfirmasi dalam ruang lingkup proyek Anda.