Բազմալեզու գործարկումը translation task չէ։ Դա route-երի, բովանդակության, interface state-երի, metadata-ի, որոնման ազդանշանների և production behavior-ի համակարգված release է։
Սկսեք route × լեզու × indexability մատրիցից
| Route | EN | HY | RU | Indexability որոշում |
|---|---|---|---|---|
| Առևտրային service | Ամբողջական | Ամբողջական | Ամբողջական | Index՝ յուրաքանչյուր տարբերակի QA-ից հետո |
| Փորձագիտական article | Ամբողջական | Ամբողջական | Ամբողջական | Յուրաքանչյուր էջի փաստերը, canonical-ը և parity-ն առանձին հաստատել |
| Contact | Ամբողջական | Ամբողջական | Ամբողջական | Պահպանել փաստերի և form behavior-ի համարժեքությունը |
Մատրիցը պետք է ներառի նաև title, description, H1, navigation, breadcrumb, button, form, error, empty state, alt, caption, schema language և switcher destination։ Տեսանելի տեքստի թարգմանությունը դեռ ամբողջական տեղայնացում չէ։
Գործարկման հերթականությունը
- Սառեցնել route inventory-ն։Գրանցել յուրաքանչյուր լեզվի իրական URL-ը, status-ը և owner-ը։
- Հաստատել content parity-ն։Նպատակ, փաստեր, սահմանափակումներ, CTA և կիրառելի assets։
- Ստուգել UI-ն ու մատչելիությունը։Keyboard, focus, form, menu, table, checklist և 320/390/1440 layout։
- Ստուգել search-facing controls-ը։Title/H1, canonical, hreflang, robots, sitemap և schema։
- Կառուցել ու կրկին crawl անել production-ը։Links, assets, console, redirects, contact prefill և release parity։
- Սահմանել post-launch ownership-ը։Search Console, monitoring, փոփոխությունների արձանագրում և rollback։
Բնօրինակ կիրառելի նյութ · Տարբերակ 1.0
Բազմալեզու կայքի գործարկման QA ստուգաթերթ
42 կետ · 20 օգոստոսի 2026 · Տպման համար հարմար HTML
Սա գործարկման կարգապահության framework է։ Այն չի փոխարինում անկախ accessibility audit-ին, security test-ին, իրավական ստուգմանը կամ production monitoring-ին։ Յուրաքանչյուր թիմ պետք է ընտրի իր իրական ռիսկին համապատասխան ընդունման չափանիշներ։
ArmDark-ի թափանցիկ self-example-ը
Phase 3C-ի evidence inventory-ն գրանցել էր ArmDark-ի այն ժամանակվա build-ի սահմանը՝ 42 HTML էջ, 39 sitemap URL և 12 schema type, repository validator-ի 0 error ու 0 warning արդյունքով։ Այդ snapshot-ը ցույց է տալիս միայն, որ սահմանված ներքին ստուգումներն անցել են տվյալ build-ի վրա։ Այն չի ապացուցում արտադրական uptime, ranking, traffic, client outcome կամ այլ նախագծերի որակ։
Այս հոդվածների ավելացումից հետո baseline-ը փոխվում է, ուստի նոր release-ը պետք է նորից հաշվվի և ստուգվի։ Հին թիվը չի կարելի ավտոմատ փոխանցել նոր build-ին։
«QA անցել է» արտահայտությունը թույլ է։ Ավելի օգտակար է նշել՝ ինչ էջեր, ինչ կանոններ, որ build-ը և ինչ հայտնի սահմանափակումներ են ստուգվել։
Գործարկումն ավարտվում է production verification-ով, ոչ upload-ով
Upload-ից հետո բացեք իրական HTTPS URL-ները, ստուգեք redirect-ները, canonical/hreflang-ը, robots-ը, sitemap-ը, schema-ն, ներքին հղումները, form behavior-ը, կարևոր media-ն և console-ը։ Search Console-ում sitemap submission-ը և URL inspection-ը owner-ի հետագա աշխատանք են, ոչ build-ի ավտոմատ ապացույց։
Փոփոխությունից հետո թարմացրեք dateModified-ը միայն այն ժամանակ, երբ տեսանելի խմբագրական բովանդակությունը կամ մեթոդաբանությունն իսկապես փոխվել է։ CSS կամ rebuild hash-ը ինքնին հոդվածի նոր խմբագրական ամսաթիվ չէ։
Առաջնային աղբյուրներ
- Google՝ localized versions — hreflang, գոյություն ունեցող համարժեք էջեր և locale ազդանշաններ։
- Google՝ sitemap — canonical indexable URL-ների ներառում։
- W3C WAI՝ preliminary checks — keyboard, headings, contrast, forms և այլ նախնական accessibility ստուգումներ։