Artikel terakhir tentang
integrasi Serge +
Smartcat . Dalam artikel ini, saya akan memberi tahu Anda bagaimana kami mengukur Serge ke seluruh perusahaan, mempertimbangkan 4 integrasi non-standar dan, sebagai bonus, berbicara tentang 2 fitur yang dapat menyederhanakan hidup Anda.
Artikel sebelumnya:
20 proyek, 20 bahasa, batas waktu kemarin20 proyek, 20 bahasa, batas waktu kemarin. Bagian 2Skalabilitas
Dalam artikel sebelumnya, saya berbicara tentang cara mengkonfigurasi Serge untuk repositori tunggal. Di perusahaan kami, kami memiliki beberapa lusin repositori yang membutuhkan terjemahan, sehingga server terpisah untuk pelokalan dialokasikan. Struktur file dan lingkungan di atasnya benar-benar identik dengan apa yang dijelaskan dalam artikel sebelumnya. Setiap repositori menggunakan instance Serge-nya sendiri. Agar tidak menjalankan perintah secara manual, setiap instance memiliki mahkota, yang secara berturut-turut menjalankan perintah Serge: menerima baris baru dari repositori, menerima terjemahan baru, penguraian, mengirim baris baru ke Smartcat dan mengirim terjemahan baru ke Gitlab.
Opsi integrasi
Dua set bahasa dalam satu repositori
Mari kita mulai dengan kasing paling sederhana. Bayangkan repositori Anda memiliki beberapa set file sumber daya. Sebagai contoh, string klien dan API aplikasi disimpan dalam repositori yang sama, tetapi dalam direktori yang berbeda. Klien diterjemahkan ke dalam 20 bahasa, API ke dalam 6.
Tujuan : untuk mengatur persediaan terjemahan yang independen di setiap direktori.
Solusi :
- Menyiapkan 2 proyek di Smartcat: dalam 6 bahasa dan dalam 20.
- Menyiapkan 2 proyek di server pelokalan.
- Pada proyek pertama, tambahkan baris $ unmerged_branch_mask = '^ (translateAPI-)' kami di file project1.cfg ; # proses cabut cabang yang tidak cocok dengan topeng ini , di mana " translateAPI- " adalah awalan nama cabang. Awalan akan menunjukkan kepada Serge bahwa cabang ini membutuhkan terjemahan di direktori API.
- Dalam file project1.serge.tmpl , tentukan path ke file sumber daya di direktori API di parameter source_dir .
- Demikian pula, untuk proyek kedua dalam file project2.cfg tambahkan baris $ unmerged_branch_mask kami = '^ (translateCLIENT-)'; # memproses cabang-cabang yang tidak digabung yang cocok dengan topeng ini , di mana " translateCLIENT " adalah awalan untuk cabang-cabang dari proyek ini. Awalan akan menunjukkan kepada Serge bahwa cabang ini membutuhkan terjemahan di direktori Klien.
- Dalam file project2.serge.tmpl , tentukan path ke file sumber daya di direktori CLIENT dalam parameter source_dir .
Harap dicatat bahwa awalan harus unik di antara semua proyek yang dikonfigurasi untuk satu repositori.
Secara total, kami memiliki 2 proyek di Smartcat dan 2 proyek yang sesuai di server lokalisasi. Kedua proyek melihat repositori yang sama di Gitlab, tetapi di direktori yang berbeda. Serge, menggunakan awalan cabang, mengerti baris mana yang harus dia kirim untuk terjemahan. Untuk menghitung diff, cabang-basis terjemahan yang sama digunakan.
Kesombongan Lokalisasi
Di perusahaan kami, semua produk, termasuk dokumentasi, dilokalkan. Sekarang kami memperkenalkan dokumentasi auto-generation dari angkuh, dan kami dihadapkan dengan kebutuhan untuk melokalisasikannya.
Tugas : melokalkan kesombongan dengan sedikit usaha.
Solusi : Dalam file
myproject.tmpl.serge , tambahkan objek
data ke objek
parser dan cantumkan di dalamnya bidang-bidang yang nilainya harus diekstraksi dan dikirim untuk diterjemahkan:
parser { plugin parse_json data { path_matches \/(summary|description)$ } }
Tugas serupa : perlu menerjemahkan teks dari file, tetapi tidak semua, tetapi hanya yang legal. Teks-teks lain disediakan oleh tim pemasaran. Agar tidak menyulitkan struktur dan tidak membuat file tambahan untuk teks hukum, kunci dari semua baris hukum menerima awalan "legal":
parser { plugin parse_json data { path_matches ^\/legal\..* } }
Seluk-beluk terjemahan hukum
Kasus lain yang menarik. Kami memiliki dokumen hukum, yang persyaratannya bervariasi dari satu negara ke negara. Tetapi, bagaimanapun, ini adalah satu aplikasi dan file sumber daya berada di direktori yang sama.
Tujuan : dalam rangka satu proyek untuk menerjemahkan beberapa dokumen, setiap dokumen harus diterjemahkan ke dalam satu bahasa tertentu.
Apa yang telah dilakukan :
- Direktori yang sesuai dibuat untuk setiap negara, di dalamnya terdapat file sumber bahasa Inggris yang relevan dengan negara itu.
- Path untuk variabel source_dir ditentukan ke direktori bersama dengan file sumber.
- Kami mengaktifkan pencarian untuk file sumber di semua subdirektori : source_process_subdirs YA
- Kami menambahkan plugin baru ke daftar yang disebut plug-in, yang memungkinkan Anda mengirim setiap file sumber daya spesifik ke bahasa yang diinginkan. Sebagai panduan, gunakan nama direktori tempat ia berada:
callback_plugins { :feature_branch { plugin feature_branch data { master_job job.base-translate } } :limit_languages { plugin limit_languages data {
Lokalisasi saat menyimpan baris dalam database
Sistem kami memiliki bagian dari kode yang menyimpan terjemahan dalam database, dan karena beberapa alasan ia tidak dapat pindah ke file sumber daya dalam repositori. Namun, kami harus dapat mengirimkan terjemahan dengan cepat dan otomatis.
Tugas : Mengatur proses pelokalan berkelanjutan jika baris tidak disimpan dalam repositori, tetapi dalam database.
Solusi :
- Buat repositori, kumpulkan, dan kelompokkan di dalamnya semua baris dari database sesuai dengan prinsip yang nyaman bagi kami (dengan jumlah bahasa terjemahan atau produk).
- Buat proyek di Smartcat.
- Mulai siklus standar pelokalan berkelanjutan.
- Gabungkan cabang terjemahan ke cabang terjemahan dasar.
- Dengan mahkota, periksa nilai hash dari commit terakhir di base-translate. Jika hash telah berubah, yaitu, terjemahan baru telah dihasilkan, parsing perbedaan antara hash lama dan saat ini, dan kirim baris baru / ubah ke basis data.
Fitur Bonus
Lansiran
Lansiran Smartcat dasar tidak cocok untuk kami, karena setiap tim ingin menerima pemberitahuan hanya tentang cabang-cabangnya dan hanya tentang kesiapan terjemahan yang lengkap di semua file sumber daya produk.
Diputuskan untuk membangun ketersediaan semua terjemahan dalam repositori dan, jika sudah sepenuhnya siap, kirim pemberitahuan ke messenger perusahaan, dalam kasus kami, Google Chat.
Tugas : mengatur peringatan di repositori, tempat 8 tim dapat melakukan, menduplikasi semua peringatan di saluran departemen dokumentasi teknis.
Solusi :
- Setuju dengan masing-masing tim bahwa nama cabang harus berisi nama tim. Masih menggunakan terjemahan awalan- untuk menunjukkan cabang yang perlu diterjemahkan.
- Buat pipa yang hanya berjalan untuk cabang yang diawali dengan translate-.
- Di jalur pipa, tentukan perintah yang dimiliki cabang, periksa keberadaan garis dengan nilai kosong, dan, jika tidak ada, kirim pemberitahuan kesiapan ke saluran yang sesuai. Karena kodenya cukup banyak, saya memasukkannya ke dalam skrip.
Ci
check-translations: stage: check-translations image: node:8.14.0 tags: - devops script: - chmod +x ./notification.sh - ./notification.sh only: - base-translate - /^translate.*$/ when: always
Alert Script
Tugas Penerjemah melalui Smartcat API

Ini adalah apa yang tampak seperti manajer lokalisasi kami ketika tiba saatnya untuk menetapkan semua cabang untuk terjemahan.
Rata-rata, kami memiliki lebih dari 10 cabang dalam pekerjaan kami setiap hari. Di Smartcat, setiap pasangan bahasa adalah dokumen terpisah, dan penerjemah harus ditugaskan untuk setiap dokumen tersebut. Secara manual. Bayangkan: 40-60 janji setiap hari. Untuk menyederhanakan proses ini, kami membuat janji melalui API, dan juga memasukkannya ke dalam saluran pipa. Pekerjaan ini diluncurkan oleh tombol. Sebuah pertanyaan yang masuk akal: mengapa tidak membuat penugasan otomatis saat mengirim transfer, dan tidak menempatkan pemanggilan metode pada plugin Smartcat, dan tidak dalam pipa?
Ada beberapa alasan untuk keputusan ini:
- Faktor manusia. Terlepas dari kenyataan bahwa kami membangun proses dan mencoba untuk mematuhinya, baris atau garis yang belum dibaca tanpa konteks secara teratur masuk ke Smartcat. Penugasan otomatis dalam hal ini akan berarti biaya tambahan bagi kami, karena beberapa baris akan dikirim untuk terjemahan dua kali: sebelum dan setelah pengeditan.
- Distribusi peran. Proyek dikonfigurasikan dan dikelola di tingkat server pelokalan oleh insinyur pelokalan atau penulis teknis proyek. Janji temu dan komunikasi dengan penerjemah ditangani oleh manajer pelokalan. Dengan demikian, penugasan harus dapat dikelola, transparan, dan dapat diakses melalui GUI.
Solusi: ketika manajer lokalisasi menganggap bahwa garis-garis di cabang ini siap untuk terjemahan, ia menekan tombol di Gitlab. Seluruh tim penerjemah ditugaskan ke cabang ini. Tugas ini diambil oleh penerjemah yang merespons pertama.
Ci
assignee: stage: assignee image: node:8.14.0 tags: - devops script: - chmod +x ./assignee.sh - ./assignee.sh only: - base-translate - /^translate.*$/ - assignee when: manual
Skrip penugasan
Ini menyimpulkan seri artikel saya tentang mengintegrasikan dan mengkonfigurasi pelokalan berkelanjutan. Saya akan dengan senang hati menjawab pertanyaan Anda.