Tarjima avtomatlashtirish konveyerini yaratish

-Ko‘p tilli (i18n) resurslarni alohida repozitoriyga ajratish hamda avtomatik tekshirish va deploy qilishni qo‘shish tajribasi-

1. Kirish

Men mas’ul bo‘lgan turizm kontenti xizmati jami to‘rtta til va beshta til paketini qo‘llab-quvvatlaydi: asosiy til sifatida koreys tili, ingliz tili, o‘zbek tili (lotin va kirill yozuvlarida) hamda qoraqalpoq tili.

Ekranlardagi barcha matnlar — tugma nomlaridan tortib axborot xabarlari va tekshiruv xabarlarigacha — tilga xos JSON tarjima fayllariga bog‘liq.

Ushbu maqolada frontend kod bazasida boshqarilgan tarjima fayllarini alohida repozitoriyga ajratish hamda yetishmayotgan tarjimalarni avtomatik aniqlaydigan tekshirish va deploy skriptlarini yaratish tajribamni bayon qilaman.

2. Mavjud yondashuvning cheklovlari

Ajratishdan oldin tilga xos JSON fayllarini frontend loyihasida saqlardik. Matnni o‘zgartirish so‘ralganda, asosiy til faylini tahrirlab, keyin qolgan to‘rtta til faylining har biriga ayni kalitni qo‘lda qo‘shardik.

Bu yondashuv uchta asosiy muammoga ega edi.

• Hatto bitta matnni o‘zgartirish kabi kichik vazifa ham o‘zgarish kuchga kirishidan oldin butun frontendni qayta yig‘ish va deploy qilishni talab qilardi.

• Hatto bitta imlo xatosini tuzatish uchun ham CI yig‘ilishi tugashini kutishimiz kerak edi.

• Kalitlar har bir til uchun qo‘lda ko‘chirilgani sababli, ayrim tillardagina kalitlar tez-tez tushirib qoldirilardi. Natijada o‘sha tillarda so‘zlashuvchilar foydalanadigan ekranlardagina tarjima kalitining o‘zi ko‘rsatilardi yoki bo‘sh satr aks ettirilardi.

• Bunday tushirib qoldirishlarni aniqlaydigan tekshiruv jarayoni mavjud emas edi, shuning uchun muammo haqida QA yoki haqiqiy foydalanuvchi deploydan keyin aniqlamaguncha bilishning iloji yo‘q edi.

• O‘zbek tili lotin va kirill yozuvlari uchun alohida fayllarda boshqarilgani sababli, ikki yozuv o‘rtasidagi nomuvofiqliklar ayniqsa ko‘p uchrardi.

3. Takomillashtirish: til paketi repozitoriylarini ajratish

Tarjima resurslari statik fayllar bo‘lib, ular albatta ilova kod bazasi yoki deploy sikli bilan birga bo‘lishi shart emas degan fikrga asoslanib, faqat tarjima JSON fayllarini boshqarishga bag‘ishlangan repozitoriy yaratdik.

Haqiqiy xizmat infratuzilmasida statik fayllarni taqdim etadigan Kubernetes nginx Pod mavjud. Ushbu Poddagi faqat JSON fayllarini yangilash frontendni qayta deploy qilmasdan, yangi tarjimalarning keyingi so‘rovdan boshlab aks etishini ta’minlaydi.

Resurslarni alohida repozitoriyga ajratish tekshiruv mantiqini qo‘shishni ham ancha osonlashtirdi.

Qo‘llab-quvvatlanadigan tillar va tuzilma quyidagicha.

Har bir til papkasi ekran sohasiga ko‘ra to‘rtta faylga bo‘lingan: common, admin, validation va user.

Bu bir nechta odamning bitta katta faylni bir vaqtda tahrirlashi natijasida yuzaga keladigan nizolarni kamaytiradi va muammo yuz berganda qaysi soha ta’sirlanganini darhol ko‘rsatadi.

4. Tarjima kalitlarini avtomatik tekshirish: validate.js

Tekshiruv skriptini faqat Node.js’ning ichki modullari (fs, path) yordamida yozdik.

Asosiy g‘oya koreys tilidan namuna sifatida foydalanish va qolgan til fayllaridagi kalitlar to‘plamini taqqoslashdan iborat. JSON ichida button.save kabi ichma-ich tuzilmalar mavjud bo‘lgani uchun, avval tuzilmalarni nuqtali yozuvdagi yo‘llarga yoyamiz, so‘ng ularni taqqoslaymiz.

function collectKeys(obj, prefix = "") {
  const keys = [];
  Object.keys(obj).forEach((key) => {
    const currentPath = prefix ? `${prefix}.${key}` : key;
    if (typeof obj[key] === "object" && obj[key] !== null) {
      keys.push(...collectKeys(obj[key], currentPath));
    } else {
      keys.push(currentPath);
    }
  });
  return keys;
}

Asosiy tilda mavjud, ammo maqsadli tilda mavjud bo‘lmagan kalitlar Error, faqat maqsadli tilda mavjud bo‘lgan kalitlar esa Warning sifatida tasniflanadi.

Ekranni buzishi mumkin bo‘lgan haqiqiy muammoni bildiruvchi hech bo‘lmaganda bitta Error mavjud bo‘lsa, skript process.exit(1) orqali chiqish kodini qaytaradi. Ushbu skript deploy skriptining birinchi bosqichi sifatida chaqirilgani sababli, shu yerdagi noodatiy to‘xtash keyingi deploy bosqichlarining umuman ishga tushmasligiga olib keladi.

Bu tuzilma tarjimalar yetishmayotganida deploy qilishni amalda imkonsiz qiladi.

5. Avtomatlashtirilgan deploy pipeline’i

Deploy beshta bosqichdan iborat: tekshirish → tar orqali siqish → nginx Pod’ni avtomatik aniqlash → kubectl cp yordamida Pod’ga nusxalash → Pod ichida ochish va tozalash.

Jamoada macOS va Windows foydalanuvchilari bo‘lgani sababli, alohida bash va PowerShell skriptlarini yaratdik hamda ikkalasi ham doim bir xil tartibda ishlashini ta’minladik.

Har bir qayta deployda Pod nomi o‘zgargani sababli, uni kodga qotirib qo‘ymadik; buning o‘rniga har safar so‘rov yuborib aniqlaymiz.

$POD = kubectl get pod -n $NAMESPACE --no-headers |
    Where-Object   { $_ -match "^nginx" } |
    ForEach-Object { ($_ -split "\s+")[0] } |
    Select-Object  -First 1

Ma’lumot uchun, macOS’da tar ishga tushirilganda ._*. ko‘rinishidagi metadata fayllari ham yaratiladi. Agar bu fayllar Pod ichida qolsa, statik katalogni keraksiz fayllar bilan to‘ldiradi.

bash skripti ularni COPYFILE_DISABLE=1 muhit o‘zgaruvchisi va --exclude opsiyasi yordamida o‘chiradi. Windows tar bu metadata fayllarini boshidanoq yaratmaydi, shuning uchun PowerShell skriptida bunga mos mantiq mavjud emas.

Ikki skriptni bitta skriptga majburan birlashtirish o‘rniga, ularni har bir muhitda bevosita ishga tushirib tekshirganimizdan so‘ng, har bir platforma uchun amalda kerak bo‘ladigan ishlov berish qismlarinigina saqlashni tanladik.

Muammolarni bartaraf etish: faqat Windows’da muvaffaqiyatsiz yakunlangan deploy

Dastlab Pod ichida bajariladigan bir nechta shell buyrug‘ini — katalogni o‘zgartirish, arxivlarni ochish, fayllarni o‘chirish va tarkibni ro‘yxatlashni — bitta here-string ichida guruhladik va uni to‘liq holda kubectl exec’ga uzatdik.

# 최초 버전 — 여러 명령을 하나의 here-string으로 묶어 전달
$cleanupScript = @"
cd $NGINX_HTML
tar -xvf $TAR_NAME
rm $TAR_NAME
"@
kubectl exec -n $NAMESPACE $POD -- /bin/sh -c $cleanupScript

Bu yondashuv macOS bash muhitida muammosiz ishladi, biroq Windows PowerShell tashqi jarayonlarga (kubectl.exe) argumentlarni uzatishni boshqacha qayta ishlaydi, shu sababli qator uzilishlarini o‘z ichiga olgan satrlar o‘rtasidan kesilib yoki qatorma-qator bo‘linib ketdi. Natijada buyruqning faqat yarmi Pod ichida bajarilgan xatolik yuz berdi.

Sababni aniqlagach, bir nechta buyruqni bittaga birlashtirish yondashuvidan voz kechdik va kubectl exec chaqiruvlarini buyruqlar bo‘yicha ajratdik.

# 수정 버전 — 명령을 kubectl exec 호출 단위로 분리
kubectl exec -n $NAMESPACE $POD -- rm "${NGINX_HTML}/locales"
kubectl exec -n $NAMESPACE $POD -- tar -xvf "${NGINX_HTML}/${TAR_NAME}" -C $NGINX_HTML
kubectl exec -n $NAMESPACE $POD -- rm "${NGINX_HTML}/${TAR_NAME}"

Buyruqlarni alohida chaqiruvlarga ajratish PowerShell argumentlarni kesib yuborishi muammosini bartaraf etdi.

Chaqiruvlar soni to‘rttaga oshdi, biroq bular bitta Pod ustida bajariladigan lokal amallar bo‘lgani uchun xarajat deyarli sezilmadi. Bu tajriba menga platformalararo skriptlar bevosita ikkala muhitda ham ishga tushirilmaguncha haqiqatan yakunlangan hisoblanmasligini yana bir bor eslatdi.

6. Foydalari va xulosa

Repositoryni ajratib, avtomatlashtirishni qo‘shganimizdan beri matn yangilanishlari frontend deploylaridan to‘liq ajratildi va bitta skriptni ishga tushirish orqali bir necha soniya ichida qo‘llanishi mumkin. Yetishmayotgan tarjimalar ham deploydan oldin mexanik tarzda aniqlanadi, natijada muayyan tildagi foydalanuvchilargina buzilgan ekranni ko‘radigan holatlar bartaraf etildi.

Bundan tashqari, endi deploylarni macOS va Windows platformalarida bir xil tartibda amalga oshirish mumkin, bu esa deploy bo‘yicha bilimlarning faqat bir kishida to‘planib qolishi bilan bog‘liq yukni kamaytirdi.

Bu hech qanday yorqin yangi texnologiyani joriy etgan loyiha emas edi.

U taxminan 100 qatorlik validatsiya skripti, kubectl va tar kabi tanish vositalarni birlashtirishdan iborat bo‘ldi. Shunga qaramay, u qayta deploy qilish yuklamasi, yetishmayotgan tarjimalar va platformaga xos skript xatolari kabi amalda takroran yuz berib kelgan muammolarni aniq aniqlab, hal qilgani uchun muhim bo‘ldi.

Ayniqsa, faqat bevosita ishga tushirish orqali ayon bo‘ladigan, masalan, faqat Windows’da takrorlash mumkin bo‘lgan kubectl exec argumentlarini uzatish muammosi kabi masalalarni birma-bir hal qilib, keyingi bosqichda validatsiya jarayonini GitLab CI bilan bog‘lashni va muammolarni merge qilishdan oldin avtomatik ravishda filtrlashni yo‘lga qo‘ymoqchiman.

nol