Drupal էջերի ավտոմատ թարգմանություն ԱԲ-ի միջոցով

Բազմալեզու backlog-ը հատուկ հոտ ունի։ Երկուշաբթի հրապարակում եք անգլերենով, գերմաներենը խոստանում եք «այս շաբաթվա ընթացքում», իսկ ուրբաթ օրը նայում եք 47 թարմացված էջերի ու չունեք պարզ ձև պատասխանելու՝ «Իսկ… իրական կարգավիճակն ո՞րն է»։

Ես տեսել եմ թիմերի, որոնք փորձում էին սա լուծել՝ ավելացնելով էլ ավելի շատ գործընթաց․ աղյուսակներ, թարգմանության տիքեթներ, շաբաթական sync-եր։ Դա աշխատում է, մինչև ինչ-որ մեկը չփոխի գլխավոր (hero) պարբերությունը 200 էջում։ Հետո նորից սկսում եք ենթադրել։

Մեզ մոտ վերջապես աշխատեց այն, որ թարգմանությանը վերաբերվեցինք որպես արտադրական համակարգի․ TMGMT՝ հետևելու և կառավարելու համար, փոքր հատուկ մոդուլ՝ cron-ի միջոցով ավտոմատ կերպով job-եր գործարկելու համար, և ԱԲ թարգմանիչ, որը աշխատում է ֆոնում ու կարող է մեծ դաշտերը մշակել՝ բաժանելով մասերի։

Այս հոդվածը մենեջերի տեսանկյունն է՝ արդյունքներ, ռիսկեր և ինչ հարցնել ձեր թիմին, որպեսզի վերջում «լուռ խառնաշփոթ» չստանաք։

Նախ՝ ինչ է իրականում նշանակում «ավտոմատ թարգմանություն»-ը (Drupal-ի տերմիններով)

Եթե պատկերացնում եք կախարդական կոճակ, որը ակնթարթորեն ամբողջ կայքը դարձնում է հինգ լեզվով, մոռացեք։ Հուսալի տարբերակը ավելի դանդաղ ու ավելի ձանձրալի է․

• Հայտնաբերվում է նոր կամ թարմացված բովանդակությունը։
• Ստեղծվում և հետևվում է թարգմանության job-ը։
• Աշխատանքը կատարվում է ֆոնում՝ ըստ ժամանակացույցի։
• Արդյունքները հասնում են վերանայման քայլի (կամ ավտոմատ ընդունվում են, եթե ընտրում եք այդ ռիսկը)։
• Թարգմանված բովանդակությունը հրապարակվում է, երբ համապատասխանում է ձեր կանոններին։

Այդ «job» գաղափարն է, որ TMGMT-ին դարձնում է լավ հիմք։ Այն կառուցված է թարգմանությունը կառավարելու համար որպես աշխատանք՝ վիճակներով, հետևումով, աղբյուրներով և թարգմանիչի փլագիններով։

Այսինքն՝ դուք «ԱԲ թարգմանություն» չեք գնում։ Դուք գնում եք workflow, որը կարող եք չափել։

Ինչու cron-ն ու queue-երը «իրականացման մանրուք» չեն

Մենեջերները սովորաբար լսում են «cron» ու մտածում՝ «պլանավորված առաջադրանք է, լավ»։ Բայց Drupal-ի ավտոմատ cron-ը աշխատում է ժամանակացույցով, որը կարող է շեղվել ցածր տրաֆիկի պայմաններում, և լռելյայն կարգավորումներում կարող է ծանրաբեռնել օգտատերերի request-երը։

Թարգմանության job-երը ծանր են։ Դրանք ներառում են արտաքին API կանչեր, retry-ներ և երբեմն էլ երկար տեքստ։ Ուստի հուսալի օրինաչափությունն է՝ աշխատանքը հերթագրել (queue), ապա թույլ տալ, որ cron-ը մշակվի վերահսկվող չափաբաժիններով։

Ահա դրա մենեջերական թարգմանությունը․

• Ձեր խմբագիրները չեն սպասում թարգմանությանը։
• Ձեր կայքում latency-ի պիկ չի լինում, որովհետև ինչ-որ մեկը երկար էջ հրապարակեց։
• Դուք կարող եք կարգավորել throughput-ը՝ հատկացնելով ավելի շատ կամ ավելի քիչ ֆոնային ժամանակ։
• Խափանումները մեկուսացվում են աշխատանքի փոքր միավորների մակարդակում՝ ամբողջ վազքը չկործանելու փոխարեն։

Եթե ձեր թիմը սա չի պլանավորել, դուք ավտոմատացում չեք ստանալու։ Դուք ստանալու եք նոր failure mode։

ԱԲ մասը․ ինչ եք ստանում, և ինչ՝ ոչ

ԱԲ թարգմանչի համար մենք օգտագործում ենք TMGMT-ի հետ համատեղելի մոտեցում, որպեսզի թարգմանությունը դեռ կառավարվի job-երով ու workflow-ով, ոչ թե մեկանգամյա սկրիպտներով։

Նախագծային տեսանկյունից մատակարարի ընտրությունը ավելի կարևոր է, քան մարդիկ սպասում են։ Դա ձեզ տալիս է ընտրանքներ ապագայում․

• Կարող եք փոխել մոդելները, երբ արժեքը փոխվում է։
• Կարող եք զգայուն բովանդակությունը route անել այլ կերպ, եթե քաղաքականությունը պահանջի։
• Կարող եք ըստ լեզվի հարմարեցնել prompt-ի ոճը՝ tone drift-ը նվազեցնելու համար։
• Կարող եք թարգմանության կարգավորումները դիտարկել որպես կոնֆիգուրացիա, ոչ թե hard-coded լոգիկա։

Բայց ներսում մի՛ գերխոստացեք։ ԱԲ թարգմանությունը արագ է և երբեմն զարմանալիորեն լավ, բայց այն միևնույն է կառավարման կարիք ունի։ Review workflow-ները գոյություն ունեն պատճառներով։

Ամենամեծ օպերացիոն ռիսկը․ երկար Body դաշտեր

Սա այն հատվածն է, որի մասին PM-երը սովորաբար լսում են միայն առաջին ինցիդենտից հետո։

Մեծ Body դաշտերը (դոկումենտացիա, քաղաքականության էջեր, շատ ներկառուցված markup ունեցող էջեր) այն տեղն են, որտեղ «պարզ» ԱԲ թարգմանությունը կոտրվում է։ Երբեմն՝ բարձրաձայն։ Ավելի հաճախ՝ լուռ․ մասնակի արդյունք, անհամաչափ ձևավորում կամ կոտրված HTML, որը անցնում է մինչև ինչ-որ մեկը դա նկատի live կայքում։

Մեր լուծումը «ավելի լավ prompting»-ը չէ։ Դա ինժեներական մոտեցում է․

• Թարգմանել ֆոնում, ոչ թե օգտատիրոջ request-ի ճանապարհին։
• Մեծ Body արժեքները բաժանել մասերի, որոնք մնում են գործնական սահմաններում։
• Վերահավաքել սկզբնական հերթականությամբ։
• Retry անել մասերի մակարդակով, որպեսզի մեկ խափանումը չբլոկի ամբողջ էջը։

Chunking-ը փոխհատուցում ունի․ տերմինաբանությունը կարող է շեղվել մասերի միջև։ Դա մեղմացնում եք թեթև գլոսարիով կամ ըստ լեզվի ոճական կանոններով։

Ի՞նչ է անում հատուկ մոդուլը (և ինչու է պետք այն)

TMGMT-ը workflow-ի շարժիչն է, բայց ինչ-որ բան դեռ պետք է որոշի՝ երբ ստեղծվի թարգմանության job-ը։ Դա հենց հատուկ մոդուլի գործն է․

• Հայտնաբերում է բովանդակության փոփոխությունները։
• Որոշում է, թե որ լեզուներն են պահանջվում տվյալ content type-ի համար։
• Ավտոմատ ստեղծում կամ թարմացնում է թարգմանության job-երը։
• Աշխատանքը ուղարկում է queue, որպեսզի cron-ը մշակվի այն ավելի ուշ։

Սա ձեզ տալիս է կանխատեսելի օպերացիոն ռիթմ։ Եվ թարգմանությունը դարձնում է հրապարակման հիգիենայի մաս՝ առանձին նախագծային հոսքի փոխարեն։

Ավելի մեծ ծրագրերում պետք են հստակ կանոններ՝ որ content type-երն են ավտոմատ թարգմանվում, որոնք են պահանջում review, և ինչ է տեղի ունենում փոքր խմբագրումների դեպքում՝ համեմատած մեծ վերագրումների հետ։ Առանց կանոնների ավտոմատացումը վերածվում է «անսպասելի վարքի»։

Ինչ չափել (որպեսզի հասկանաք՝ աշխատո՞ւմ է)

Եթե հաջողությունը չսահմանեք, թիմը այն կսահմանի ձեր փոխարեն, և կարող է ձեզ դուր չգալ այդ սահմանումը։ Ահա չափանիշներ, որոնք իրականում կապվում են արդյունքների հետ․

• Թարգմանության լատենտություն (latency): միջին (median) ժամանակը բովանդակության հրապարակումից/թարմացումից մինչև թարգմանությունը հասանելի լինի review-ի համար։
• Backlog-ի չափը: “needs translation” կամ “needs review” վիճակներում նստած տարրերի քանակը։
• Վերախմբագրման հաճախականություն (rework rate): որքան հաճախ են մարդիկ խմբագրում թարգմանությունները ԱԲ արդյունքից հետո։
• Խափանումների հաճախականություն (failure rate): retry-ներ, կախված job-եր կամ ձևավորման խնդիրներ, որոնք պահանջում են միջամտություն։

Օգտագործեք job tracking-ը որպես հաշվետվության մակերես՝ փոխարենը զուգահեռ դաշբորդ հնարելու։

Կառավարում (governance)․ որտեղ նախագծերը հաջողում են կամ լուռ ամոթացնում ձեզ

Ավտոմատ թարգմանության նկատմամբ վստահությունը կորցնելու ամենաարագ ճանապարհը իրավականորեն ռիսկային կամ բրենդին վնասող ինչ‑որ բան հրապարակելն է։ Ավտոմատացումը մեծացնում է վնասի շառավիղը։

Ձեզ պետք են քաղաքականության որոշումներ, ոչ թե միայն մոդուլներ․

• Որ content type-երը կարող են ավտոմատ հրապարակել ԱԲ թարգմանությունները։
• Որոնք պետք է պարտադիր անցնեն review։
• Ո՞վ է պատասխանատու (owner) գլոսարի տերմինների համար՝ ապրանքային անուններ, իրավական արտահայտություններ, կարգավորվող լեզու։
• Ի՞նչ է ձեր rollback պլանը, եթե մոդելի թարմացումը փոխի տոնը։

Հիբրիդ մոդելը հաճախ առողջ կոմպրոմիս է․ ԱԲ‑ն ծածկում է ծավալը, մարդիկ՝ ռիսկը։

Գործարկման պլան, որը չի «պայթեցնի» ձեր խմբագրական թիմը

Եթե սա միանգամից անեք, խմբագիրները կզգան, թե հողը շարժվեց իրենց ոտքերի տակ։ Կա ավելի լավ ճանապարհ։

Սկսեք մի content type-ից, որը հստակ կառուցվածք ունի և ավելի ցածր ռիսկ։ Նորություններ, միջոցառումների էջեր, FAQ-եր։ Կայունացրեք pipeline-ը։ Հետո ընդլայնեք դեպի «կեղտոտը»՝ երկարֆորմ էջեր, դոկումենտացիա, ծանր ձևավորում ունեցող մարքեթինգային էջեր։

Նաև՝ վաղ փուլում որոշեք, թե ինչպես եք աշխատեցնելու cron-ը։ Հուսալիությունն ու throughput-ը ազդում են առաքման ժամկետների վրա այնպես, ինչպես թիմերը հաճախ թերագնահատում են։ Սա տեխնիկական ծանոթագրություն չէ։

Հարցը, որը կփորձեի տալ՝ մինչև սա green-light անելը

Երբ համակարգը աշխատում է, թարգմանությունը դառնում է ֆոնային աղմուկ։ Դա է նպատակը։

Բայց ահա անհարմար հարցը՝ դուք օպտիմիզացնում եք արագությա՞ն, թե՞ վստահության համար։ Որովհետև պատասխանը որոշում է՝ կկատարե՞ք auto-publish, որքան խիստ կլինի review-ը, որ լեզուներից կսկսեք rollout-ը և որքան կներդնեք տերմինաբանական վերահսկման մեջ։

Եթե ասեք՝ ինչ տեսակի կայք եք վարում (մարքեթինգային, դոկումենտացիոն, թե խառը) և քանի լեզու է scope-ում, կարող եմ առաջարկել rollout մոտեցում, որը համապատասխանում է ռիսկային պրոֆիլին՝ փոխարենը ձևացնել, թե մեկ workflow-ը բոլորին է համապատասխանում։

Փնտրու՞մ եք շուկայում լավագույն Drupal մշակման ընկերությունը։ Դուք հենց նոր գտաք այն։

Մենք Drupal-ի վրա կենտրոնացած ամենամեծ թվային գործակալությունն ենք, ստեղծված՝ արագ, անվտանգ և մասշտաբվող հարթակներ մատակարարելու համար՝ առանց փոխզիջումների։ Նոր կառուցումներից ու վերադիզայններից մինչև միգրացիաներ և երկարաժամկետ աջակցություն՝ մեր Drupal փորձագետները տալիս են enterprise մակարդակի արդյունքներ՝ boutique մակարդակի ուշադրությամբ։

Ամրագրեք զանգ այսօր, և եկեք ձեր Drupal roadmap-ը դարձնենք բարձր արդյունավետ իրականություն։