Bayangkan: Anda memiliki 7 tim pengembangan yang berjumlah lebih dari 100 orang. Mereka secara bersamaan melihat 13 aplikasi. Pekerjaan dilakukan di 20 repositori.
Semua aplikasi perlu diterjemahkan. Beberapa dalam 6 bahasa, beberapa dalam 20. Dan beberapa dalam 13, tetapi ini adalah set bahasa yang sama sekali berbeda, tidak termasuk dalam 20 bahasa sebelumnya.
Setiap orang memiliki tumpukan yang berbeda, sebagai hasil dari format garis yang berbeda: js, json, ts, yaml atau yml. Dan beberapa masih menyimpan teks mereka di database.
Anda bekerja pada Agile: pengiriman nilai harian, sprint dua minggu. DoR mencakup semua terjemahan yang diperlukan. Yah, tentu saja, terjemahan diperlukan kemarin untuk punya waktu untuk menguji.
Ada departemen penulis teknis. Siapa penulis teknis? Ini adalah orang yang menulis dokumentasi eksternal, terkadang internal. Menulis semua jenis teks yang dapat dilihat pengguna atau mitra: teks front-end, teks pesan, respons API, kesalahan. Menemani proses pengembangan untuk dibenamkan dalam teknologi dan logika bisnis. Dan menyediakan pengiriman terjemahan ke aplikasi secara tepat waktu.
Ada juga posisi copywriter-penerjemah dan manajer pelokalan. Ini adalah orang yang membuat semua teks dalam bahasa Inggris, dan juga memantau konsistensi terjemahan, menunjuk penerjemah, dan menyelesaikan semua masalah terkait.
Perhatian, pertanyaannya adalah: berapa banyak spesifikasi teknis, copywriter dan manajer pelokalan yang diperlukan agar tidak menghalangi pengembangan dan tidak melukai seluruh departemen teknis?
Dalam kasus kami, kami mengelola 4 layanan teknis dan 1 manajer lokalisasi copywriter. Pengiriman transfer rata-rata cocok dalam satu hari kerja dan tidak pernah melebihi tiga hari kerja. Saya harap Anda menemukan itu menarik.
Bagaimana kita sampai pada ini?
6 tahun yang lalu kami bekerja di lembar Google dan DB. Yaitu, jika selama proses pengembangan muncul garis untuk terjemahan, kami menyalinnya ke tablet, dan kemudian mengirimkannya melalui pos ke terjemahan. Ketika terjemahan siap, itu secara manual dituangkan ke dalam database. Satu-satunya nilai tambah dari solusi ini adalah Anda tidak perlu meletakkan kembali aplikasi untuk melihat baris baru. Tetapi jika ada kesalahan dalam terjemahan, itu tidak akan berhasil mundur. Tidak ada memori terjemahan, tidak ada glosarium. Konsistensi terjemahan dicapai dengan metode tatapan.
Upaya pertama
Versi pertama yang mengotomatiskan proses ini tampak seperti ini: ketika seorang pengembang memiliki baris, ia menambahkannya ke cabang baru di repositori khusus untuk terjemahan. Kemudian, di cabang yang sama, sebuah pipa diluncurkan, yang oleh API, mengirim semua baris yang berbeda untuk diterjemahkan. Benar, terjemahan seharusnya sudah kembali ke database, tetapi gagal memuat garis dari sumber daya eksternal ke database internal melalui API.
Apa yang diberikan integrasi seperti itu? Sebuah langkah telah dihapus di mana penulis teknis perlu mengumpulkan semuanya menjadi satu tabel, mengirim secara manual, dan kemudian membagi terjemahan yang diterima dengan aplikasi dan dengan jumlah bahasa. Dalam hal ini, kalimat-kalimat tersebut segera dikirim untuk diterjemahkan sebagai bagian dari proyek dengan nama yang sama dengan aplikasi yang dimaksudkan. Sebagai hasilnya, penulis teknis menerima satu set arsip untuk setiap aplikasi yang pekerjaannya dilakukan. Ini secara signifikan mengurangi pangsa tenaga kerja manual. Selain itu, memori terjemahan diimplementasikan di sisi penyedia. Tetapi solusi ini juga mempertahankan sejumlah kelemahan: menyimpan baris dalam database tidak memungkinkan manajemen baris penuh di pihak kami dan masih menyiratkan sebagian besar pekerjaan manual.
Nyeri dan lokalisasi terus menerus
Integrasi berikut membawa banyak penderitaan bagi para pengembang. Tampaknya bagi saya bahwa mereka yang menangkapnya masih memiliki mata berkedut pada kata "lokalisasi". Ini adalah integrasi pertama dengan Serge dan Smartcat.
Di sini penting untuk mengetahui apa itu Serge dan Smartcat.
Serge adalah utilitas yang mendukung git. Dia tahu cara mendapatkan baris yang diperlukan dari cabang, mengirimnya untuk terjemahan, dan kemudian mengembalikan terjemahan untuk baris yang sama ke cabang yang sama saja. Kami juga membutuhkan plugin yang akan memanggil API sistem CAT di mana kami menerjemahkan. Plugin harus menerima baris baru dari Serge dan mengembalikan terjemahan siap ke Serge.
Smartcat adalah sistem CAT dengan dukungan untuk glosarium, memori terjemahan, placeholder. Selain itu, Smartcat mengagregasi dan menyederhanakan proses penyelesaian dengan freelancer, mendukung koneksi vendor terjemahan.
Pada langkah ini, kami memindahkan baris dari database ke repositori proyek. Sekarang string harus dikirim langsung dari repositori aplikasi dan dikembalikan ke sana.
Seharusnya ini akan bekerja seperti ini: pengembang tahu dari cabang mana ia membuat cabang fitur-nya, dan perbedaan dalam file sumber daya antara dua cabang ini persis apa yang perlu diterjemahkan. Ketika seorang pengembang memiliki serangkaian terjemahan, ia memulai pekerjaan di cabangnya dengan konfigurasi Serge. Serge menghitung diff, mengekstrak baris baru, memanggil plugin dan mengirimkan baris untuk terjemahan. Ketika terjemahan siap, pengembang memanggil pekerjaan berikut: dia menyebarkan instance Serge yang dibuat pada langkah sebelumnya, menerima terjemahan yang sudah selesai dan menyerahkannya ke cabang sumber.
Solusinya ternyata tidak stabil: Serge tidak dimaksudkan untuk ditempatkan dari awal setiap kali pipa diluncurkan, para pengembang tidak ingin memikirkan perbedaan di antara cabang-cabang, dan plugin Smartcat sangat membutuhkan pembaruan dan peningkatan. Proses pengiriman jalur baru bisa memakan waktu berjam-jam. Dan, sayangnya, itu tidak selalu berhasil.
Secara teoritis, semua tahapan proses dilakukan secara otomatis, pada kenyataannya, perawatan, menghitung diff sebelum dimulainya pipa dan pemecahan masalah membutuhkan waktu lebih lama daripada melakukan tugas yang sama secara manual.
Cahaya di ujung terowongan
Pada Agustus 2018, kami telah meluncurkan versi integrasi saat ini. Kami memiliki server pelokalan. Di server untuk setiap repositori ada contoh terpisah dari Serge. Serge memindai semua cabang di repositori, mengirim baris baru untuk terjemahan dan melakukan terjemahan yang sudah selesai ke cabang asli. Dalam integrasi saat ini, semuanya cepat dan stabil. Setelah membuat cabang untuk terjemahan, garis muncul di Smartcat dalam 5-6 menit. Setelah mengonfirmasi transfer, komit terjadi serupa, dalam 5-6 menit yang sama. Waktu pengiriman untuk terjemahan hanya dibatasi oleh faktor manusia: beban kerja penerjemah, perbedaan zona waktu dan sebagainya.
Dalam artikel berikut ini saya akan memberi tahu Anda cara mengkonfigurasi integrasi Serge-Smartcat-Gitlab dari awal, dan bagaimana kami menyelesaikan berbagai tugas non-standar.
Kelanjutan:
20 proyek, 20 bahasa, batas waktu kemarin. Bagian 220 proyek, 20 bahasa, batas waktu kemarin. Bagian 3