Prinsip-prinsip dokumentasi dan lokalisasi, atau cara mendapatkan lokalisasi yang baik dengan biaya minimal

Halo semuanya!

Nama saya Denisov Alexander. Saya bekerja untuk Naumen dan bertanggung jawab untuk mendokumentasikan dan melokalkan produk perangkat lunak Naumen Contact Center (NCC).

Dalam artikel ini saya akan berbicara tentang masalah yang kami temui ketika melokalkan NCC dalam bahasa Inggris dan Jerman dan bagaimana kami memecahkan masalah ini. Tentu saja, hari ini kami telah menyelesaikan jauh dari semua tugas kami, dan kemungkinan besar proses ini umumnya tidak ada habisnya. Artikel tersebut mempertimbangkan visi keseluruhan proses sebagai keseluruhan dan prinsip-prinsip yang kami coba patuhi atau yang mulai kami coba terapkan. Materi akan berguna bagi mereka yang baru mulai merancang perangkat lunak, berencana melokalkannya atau sedang menghadapi masalah, tetapi belum tahu bagaimana menyelesaikannya.

Pendahuluan

Seringkali sebuah perusahaan berpikir tentang pelokalan perangkat lunak ketika produk siap dan dokumentasi telah ditulis untuk itu. Dan seringkali juga terlambat untuk melakukan sesuatu untuk mendapatkan lokalisasi yang baik dalam waktu singkat dan tidak menghabiskan banyak sumber daya untuk itu.

Tidak mungkin untuk menulis secara terperinci tentang semua masalah dan kesulitan dalam satu artikel, jadi saya akan berbicara sedikit tentang tahapan utama dokumentasi dan lokalisasi dan menyentuh beberapa, menurut pendapat saya, masalah yang paling penting:

• Apa tahapan siklus hidup pengembangan perangkat lunak yang memengaruhi kualitas dokumentasi dan lokalisasi?
• Apa dan kapan harus dilakukan pada setiap tahap?
• Apa pendekatan, kemampuan alat yang dapat digunakan untuk memecahkan masalah dan masalah dari setiap tahap?
• Seperti org. Apakah struktur memengaruhi dokumentasi dan lokalisasi?
• Bagaimana cara mengatur menerima umpan balik dari pengguna dokumentasi?
• Bagaimana cara menghemat waktu dan biaya keuangan pada setiap tahap?

Berdasarkan pengalaman bertahun-tahun saya dalam mendokumentasikan dan melokalisasi NCC, saya akan mencoba menjawab pertanyaan-pertanyaan ini.

Fitur NCC dan proses pengembangan

Naumen Contact Center adalah perangkat lunak canggih untuk mengatur pusat kontak perusahaan atau outsourcing yang besar.

Apa kesulitan mendokumentasikan dan melokalkan sistem ini:

1. Sistem tidak mendung.
2. Setup yang kompleks, banyak integrasi dengan berbagai sistem.
3. Dukungan untuk banyak versi.
4. Sebagai hasil dari paragraf 1-3, kami memiliki implementasi dan pembaruan yang kompleks. Setiap klien memiliki versinya sendiri, konfigurasi dan integrasi sendiri dengan berbagai sistem.
5. Sistem ini tidak masif, hanya digunakan oleh bisnis besar. Oleh karena itu, jumlah pelanggan tidak terlalu besar dibandingkan dengan produk massal kecil.
6. Sejumlah besar persyaratan khusus.
7. Model multi-peran. Dan ini berarti bahwa dokumentasi dan antarmuka harus disesuaikan dengan karakteristik masing-masing peran (tingkat pengetahuan dan fitur tugas).
8. Antarmuka sistem berisi sekitar 30.000 baris teks dan sekitar 3.000 halaman dokumentasi teknis yang rumit ditulis.
9. Rilis dirilis 2-3 kali setahun.
10. Setelah setiap rilis, sekitar 10% dari teks antarmuka dan dokumentasi diperbarui dan ditambah.
11. 3 bahasa: Rusia (sumber), Inggris dan Jerman.

Siklus hidup pengembangan

Mari kita lihat siklus hidup pengembangan perangkat lunak dan pilih hanya tahapan-tahapan yang berhubungan dengan dokumentasi dan lokalisasi:

• Pengembangan fitur. Sebagai bagian dari fase ini, teks untuk antarmuka dikembangkan.
• Dokumentasi Sebagai bagian dari fase ini, dokumentasi dikembangkan, termasuk pembuatan tangkapan layar dan gambar lainnya.
• Lokalisasi antarmuka dalam beberapa bahasa.
• Terjemahan dokumentasi ke bahasa lain, termasuk lokalisasi tangkapan layar dan gambar lainnya.

Sekarang mari kita bayangkan bahwa satu kesalahan kecil terjadi pada antarmuka. Secara otomatis berlaku untuk setiap tahap, untuk beberapa versi dan bahasa.



Kesalahan tambahan mungkin muncul pada setiap tahap, yaitu, sebagai hasilnya, kita bisa mendapatkan sejumlah besar kesalahan. Kesalahan antarmuka kecil kemungkinan besar tidak akan pernah diperbaiki, selalu ada tugas yang lebih penting. Dan jika Anda mengeditnya, maka biaya pengeditan ini akan sangat tinggi, karena Anda lagi harus melalui seluruh rantai, semua versi dan bahasa. Dan semakin banyak versi dan bahasa, semakin mahal.

Dalam konteks ini, orang tidak dapat hanya berbicara tentang kualitas lokalisasi antarmuka atau tentang kualitas dokumentasi yang diterjemahkan, karena hasil pekerjaan setiap tahap adalah dasar untuk tahap berikutnya. Itulah mengapa sangat penting untuk segera melakukan segalanya dengan benar di setiap tahap. Dan itulah mengapa perlu mempertimbangkan pengembangan perangkat lunak, dokumentasi, dan lokalisasi sebagai tahapan dari satu proses yang tidak dapat dipisahkan.

Organisasi teks dalam antarmuka

Ketika programmer kami mengambil lokalisasi sistem, itu sama sekali tidak siap untuk ini. Teks antarmuka disimpan dalam kode, dan keinginan manajemen adalah: "lakukan semuanya dengan cepat." Pemrogram menulis naskah yang mengeluarkan semua teks dari kode dan melemparkannya ke file sumber daya, dan hari berikutnya mereka memberikan file sumber daya kepada karyawan pertama yang tahu bahasa Inggris, yang dengan cepat menerjemahkan semuanya ke dalam notepad. Apa yang terjadi ini dapat dilihat di bawah ini.



Gambar menunjukkan tombol sederhana, itu membuka beberapa bentuk dengan parameter, di mana parameter ini dapat diubah. Ada puluhan tombol seperti itu dalam sistem. Di Rusia, ada 3 opsi untuk tombol seperti itu, lokalisasi ke bahasa Inggris sudah berisi 7 opsi.

Dalam situasi ini, segera ada keinginan besar untuk membersihkan garis antarmuka. Untuk melakukan ini, saya mengusulkan untuk menerapkan aturan berikut:

• Pembagian semua lini menjadi kelompok-kelompok.
  
  Semua baris harus dibagi menjadi kelompok sesuai dengan jenis elemen antarmuka. Bahkan jika garis memiliki teks yang sama, aturan terjemahan yang berbeda mungkin berlaku untuk grup yang berbeda. Misalnya, aturan huruf besar untuk huruf pertama dari setiap kata dalam bahasa Inggris. Untuk beberapa jenis elemen antarmuka, digunakan, untuk yang lain tidak.
• Menghapus duplikat.
  
  Di setiap grup, masuk akal untuk menghapus semua baris duplikat, yaitu baris dengan teks yang sama. Maka akan ada satu-satunya pilihan dalam bahasa Rusia dan bahasa lainnya. Ini menghemat biaya terjemahan. Saya perhatikan bahwa kemungkinan besar garis yang diulang akan tetap ada, karena dalam beberapa kasus konteksnya mungkin berbeda. Selain itu, baris seperti itu dengan teks sumber yang sama dapat diterjemahkan dengan cara yang berbeda. Misalnya, kata Nama , dalam konteks nama seseorang, dapat diterjemahkan sebagai Nama depan , dan dalam konteks nama file, cukup Nama .
• Menambahkan konteks ke pengidentifikasi baris.
  
  Pengidentifikasi garis dapat terdiri dari pengidentifikasi garis itu sendiri dan grup yang dimiliki garis tersebut. Ini diperlukan agar penerjemah dapat menggunakan pengenal untuk memilih aturan pelokalan. Jika kami memiliki pengidentifikasi yang benar, maka proses pemeriksaan dan perbaikan kesalahan huruf besar yang sama dapat dengan mudah diotomatisasi.

Sayangnya, menerapkan aturan-aturan ini untuk semua 30.000 baris yang ada sekaligus sangat memakan waktu. Di sini kita berada pada tahap awal dan secara bertahap mengatur garis yang paling sering diulang dan mengembangkan aturan untuk garis baru. Tetapi Anda harus mengakui, itu akan menjadi super jika semua aturan dieja dan diimplementasikan segera!

Proses Dokumentasi dan Pelokalan

Mari kita lihat dokumentasi berbasis waktu dan proses pelokalan. Jika Anda mulai mendokumentasikan dan melokalkan sebelum pengembangan fitur selesai, Anda harus mengulang semuanya (mungkin beberapa kali).

Hal yang sama dengan menerjemahkan dokumentasi.

Dan jika Anda memberikan dokumentasi kepada pengguna sebelum semua pengeditan selesai, Anda dapat mengandalkan banyak komentar. Kemungkinan besar, beberapa komentar ini akan diperbaiki pada tahap terakhir pengembangan, tetapi Anda harus meluangkan waktu ekstra untuk memprosesnya.



Jika proses tidak terkoordinasi, dan kami tidak melacak semua perubahan tepat waktu, maka "tidak ada apa-apa-di mana saja" tidak akan sesuai.

Dokumentasi tidak akan cocok dengan antarmuka. Tangkapan layar tidak akan cocok dengan antarmuka dan teks dokumentasi.



Sama dengan lokalisasi. Teks antarmuka dan dokumentasi dalam bahasa sumber tidak akan cocok dengan teks antarmuka dan dokumentasi dalam bahasa lain.



Kami memutuskan bahwa saat ini kami dapat memulai setiap tahap baru hanya setelah kami menyelesaikan tahap sebelumnya.



Ya, dokumentasi dan lokalisasi kami keluar terlambat setelah rilis. Dan berbicara tentang pelokalan, kami telah mengamankan kemungkinan pelokalan berkelanjutan, tetapi kami tidak menggunakan kesempatan ini dan melakukan semua pelokalan dalam satu langkah di akhir rilis. Beberapa hari sebagai bagian dari rilis semi-tahunan adalah tahap yang sangat kecil.

Selama produk kami tidak besar, kami tidak memiliki kebutuhan mendesak untuk dokumentasi dan pelokalan untuk muncul pada hari yang sama. Kami memiliki rilis panjang, klien perusahaan besar, yang jumlahnya tidak terlalu banyak dibandingkan dengan produk kecil dan lebih besar, dan mereka tidak mulai segera menginstal versi baru produk atau meningkatkannya. Biaya pemodelan ulang yang konstan terlihat berkurang.

Masalah terminologi

Pada tahap dokumentasi dan lokalisasi, kami terus menghadapi masalah dengan terminologi:

• Entitas yang sama disebut secara berbeda, dan entitas yang berbeda dinamai sama.
• Istilah yang sama diterjemahkan dengan cara yang berbeda, dan istilah yang berbeda juga diterjemahkan dengan cara yang sama.
• Entitas dapat disamakan dengan entitas anak yang dikandungnya, atau entitas induk.
• Istilah yang gagal atau salah dipilih untuk menunjukkan suatu entitas.

Proses pengembangan kami untuk beberapa waktu tampak seperti ini:

• Analis menulis produksi.
• Penguji menguji produksinya.
• Kode pengembang.
• Penguji menguji hasilnya.

Dan ketika mencoba masuk ke dalam proses ini dengan terminologi, kami menerima alasan seperti:

• Anda akan memperlambat seluruh proses.
• Ini umumnya tidak begitu penting.
• Anda memiliki alat, Anda dapat memperbaiki semuanya nanti.

Tapi "nanti" ternyata kita tidak bisa memperbaiki semuanya. Misalnya, ada situasi ketika, karena terminologi yang tidak dipahami dengan benar, objek sistem ditempatkan pada tingkat hierarki yang salah atau digabungkan ke dalam kelompok yang salah.

Sekarang kami memeriksa persyaratan dan teks antarmuka secara paralel dengan pengujian pengaturan. Artinya, sementara penguji menulis komentar mereka, kami menulis komentar kami sendiri.



Apa yang kami lakukan selama pengujian produksi:

• Kami mengungkapkan istilah baru.
• Periksa teks antarmuka: untuk penggunaan istilah yang benar, kepatuhan dengan panduan gaya dan kepatuhan dengan peran.
• Kami mengidentifikasi baris yang ada agar tidak membuat duplikat.
• Kami menyetujui perlunya pelokalan, karena beberapa bagian antarmuka hanya dapat digunakan di satu negara.

Saat mengungkapkan istilah baru, kami menambahkannya ke daftar istilah, sementara:

• Tambahkan definisi atau konteks.
• Kami menunjukkan hubungan dengan istilah lain (menunjukkan syarat orang tua dan anak).
• Kami berusaha untuk segera menunjukkan arti bahasa Inggris, karena setelah memilih nama bahasa Inggris, terkadang menjadi jelas bahwa bahasa Rusia tidak dipilih dengan benar.

Kita dapat mengatakan bahwa karena koordinasi terminologi dan teks antarmuka pada tahap pengaturan persetujuan, kami mulai menghemat banyak waktu pada banyak koreksi pada tahap selanjutnya.

Dokumentasi

Prinsip-prinsip yang kami patuhi ketika mendokumentasikan:

• Menggunakan sistem sumber tunggal.
• Menggunakan glosarium.
• Gunakan panduan gaya.
• Pembagian dokumentasi menjadi dokumen-dokumen kecil dan mudah diasingkan.
  Ini layak dilakukan, bahkan jika format utamanya adalah Web. Jika perlu, Anda tidak dapat menerjemahkan semua dokumentasi, tetapi hanya dokumen yang paling penting, atau melakukannya secara bertahap.

Sekarang saya akan berbicara tentang beberapa aspek terpenting dari proses dokumentasi.

Gunakan kembali teks

Dalam kebanyakan sistem sumber tunggal, variabel dapat digunakan. Oleh karena itu, kami mengembangkan skrip yang secara otomatis mengonversi file sumber daya antarmuka ke file variabel. Dalam proses pengembangan dokumentasi, kami tidak mengetik teks elemen antarmuka, tetapi memasukkan variabel ke dalam teks. Jadi, dalam versi Rusia, garis-garis Rusia secara otomatis ditarik, dalam versi bahasa Inggris, Inggris, dalam bahasa Jerman Jerman.



Apa manfaatnya:

• Kesalahan dalam teks elemen antarmuka dikecualikan jika disebutkan dalam dokumentasi. Teks elemen antarmuka dalam dokumentasi selalu identik dengan teks dalam antarmuka.
• Jika baris teks telah berubah di antarmuka, mereka secara otomatis berubah dalam dokumentasi.
• Kesalahan dikecualikan saat menerjemahkan teks elemen antarmuka dalam dokumentasi.
• Seorang penerjemah menghabiskan lebih sedikit waktu untuk bekerja.

Ada banyak kalimat rangkap dalam dokumentasi. Misalnya, kalimat seperti - “Klik tombol Simpan .”. Dalam sistem sumber tunggal, proposal semacam itu dapat ditempatkan dalam cuplikan. Cuplikan adalah file kecil yang dapat dimasukkan ke halaman lain dari dokumentasi.



Seperti yang Anda lihat, teks tombol Simpan di cuplikan juga diganti dari variabel.

Ini memberikan manfaat berikut:

• Kalimat identik dalam arti di mana-mana identik, yang berarti bahwa keseragaman teks meningkat.
• Biaya pengembangan dokumentasi melalui penggunaan kembali berkurang.
• Kalimat tersebut diterjemahkan hanya 1 kali. Ini mengurangi biaya penerjemah.

Tangkapan layar dan gambar lainnya

Dalam dokumentasi kami, kami sering menggunakan tangkapan layar dan gambar lain yang mungkin mengandung teks.

Untuk mengambil tangkapan layar dalam berbagai bahasa sendiri, di bawah setiap tangkapan layar kami menulis teks yang digunakan di sana. Teks ini ditandai dan tidak muncul dalam dokumentasi yang selesai. Sebelum kami menerjemahkan dokumentasi, kami menerjemahkan teks untuk tangkapan layar. Dan selama penerjemahan dokumentasi kami mengambil tangkapan layar oleh penulis teknis tanpa pengetahuan bahasa.

Menggunakan screenshot, ada kesulitan lain. Misalnya, bagaimana melacak semua perubahan jika antarmuka mengubah satu baris teks, yang digunakan di 50 tempat?

Lalu bagaimana menemukan semua tangkapan layar dari 50 tempat ini untuk menggantikannya dalam dokumentasi?

Untuk mengatasi masalah ini, kami menggunakan alat QVisual yang kami kembangkan di Tinkoff. Proses bekerja dengannya terlihat seperti ini:

1. Selama pengembangan dokumentasi, di bawah setiap tangkapan layar kami membuat tautan ke stan tempat tangkapan layar ini diambil.
2. Pada titik tertentu, kami menyiapkan daftar semua tautan.
3. Kami memuat daftar yang diterima ke dalam QVisual.
4. QVisual berjalan melalui satu versi produk dan mengambil serangkaian tangkapan layar.
5. Selanjutnya, kami mengambil versi produk yang baru dan QVisual menjalankannya menggunakan tautan yang sama.
6. QVisual kemudian membandingkan 2 set tangkapan layar dan menghasilkan laporan. Dalam laporan, secara grafis, Anda dapat melihat perbedaan antara kedua versi. Contohnya di bawah ini. Anda dapat segera melihat bahwa dalam versi baru tangkapan layar, bidang tambahan Bahasa antarmuka pengguna telah muncul.
7. Selanjutnya, kami ulangi prosedur perbandingan (hal. 1-6) untuk setiap bahasa.
8. Kami mengambil laporan dan melihat tangkapan layar dalam dokumentasi.

Dengan demikian, kami mengurangi biaya berbagai pemeriksaan tangkapan layar manual. Selain itu, secara manual tidak selalu mungkin untuk mengidentifikasi semua kesalahan, Anda dapat mengabaikan sesuatu.

Benar, tidak semua jendela dapat dibuka menggunakan tautan dan ini hanya berfungsi untuk antarmuka berbasis web, tetapi masih menghilangkan beberapa masalah dengan memperbarui tangkapan layar.

Lokalisasi antarmuka

Sebelum melokalisasi antarmuka, jika ini belum dilakukan, Anda perlu menerjemahkan semua istilah glosarium.

Ketika glosarium diterjemahkan, pelokalan dapat dimulai. Dalam proses ini, kami mematuhi prinsip-prinsip berikut:

• Gunakan glosarium.
• Kami menggunakan memori terjemahan.
• Kami menggunakan panduan gaya.
• Kami menggunakan konteks.
• Kami menggunakan jaminan kualitas otomatis (QA).

Saya perhatikan bahwa konteksnya mungkin memiliki prioritas lebih tinggi untuk membuat keputusan terjemahan daripada memiliki baris yang sudah diterjemahkan dalam memori terjemahan. Selain itu, berdasarkan konteks, aturan terjemahan tertentu yang ditentukan dalam panduan gaya mungkin berlaku.

Ada beberapa cara untuk memberikan konteks:

• Seperti yang saya tulis di atas, konteksnya dapat diletakkan di pengenal string itu sendiri atau di bidang tambahan file sumber daya (jika formatnya memungkinkan).
• Tangkapan layar dapat ditambahkan. Saat ini, kami dapat menambahkan tangkapan layar secara manual ke garis yang sangat rumit.
• Menyediakan stan dan dokumentasi dalam bahasa sumber. Seperti yang ditunjukkan oleh latihan, metode ini tidak berhasil. Penerjemah biasanya tidak menggunakan bahan dan stan yang disediakan untuk mereka. , .

, :

• . , . .
• . 100% . , , , 10% , 90% – .
• . , .
• .
• .
• .
• (QA).

. , , .



, . « ». , . .

.

, — , . , , .

.

, QA, , .

, , . . . , .



, , «» , - .

, , ? :

• ?
  , . ( ), . , . , : , , . .
• ?
  , , . . ? , , .

:

• .
  
  , , -50 , . - 1-2 , .
• .
  
  CAT-. , (, ), .
• , , , .
• , .

Web- . , , .

. , .

. . , .

:

• .
  
  - , . . , Ctrl+Enter . . .
• .
  
  , . , , .
• .
  
  , , . , ( ), . , . .

, , , . , , .

Kesimpulan

, -, .

, , .

. .

, ! !

, !