როგორ დავამატოთ რამდენიმე ენა თქვენს აპლიკაციას ან ვებსაიტს
აპში რამდენიმე ენის დასამატებლად, გადაიტანეთ ინტერფეისის ყველა ტექსტი თარგმანის ფაილებში (თითო ენაზე ერთი), ჩატვირთეთ ისინი i18n ბიბლიოთეკით და დაამატეთ ენის გადამრთველი, რომელიც არჩევანს იმახსოვრებს. საჯარო გვერდებისთვის, რომლებიც საძიებო სისტემაში უნდა ჩანდეს, თითოეულ ენას მიანიჭეთ საკუთარი URL, მაგალითად /fr/, და ვერსიები დააკავშირეთ hreflang ტეგებით. შემდეგ მოაგვარეთ ის ნაწილები, რომლებსაც ხშირად ივიწყებენ: თარიღები, რიცხვები და ვალუტები, ზოგიერთ ენაზე გრძელი ტექსტი, მარჯვნიდან მარცხნივ წერის სისტემები და მონაცემთა ბაზაში შენახული კონტენტი.
ტერმინები, რომლებსაც შეხვდებით
- ინტერნაციონალიზაცია (i18n): კოდის მომზადება ნებისმიერი ენისთვის — ტექსტი ხისტად არ წერია, ფორმატირება ადგილობრივია, განლაგება მოქნილია. „18“ არის ასოების რაოდენობა i-სა და n-ს შორის.
- ლოკალიზაცია (l10n): აპის მორგება კონკრეტული ენისთვის ან ბაზრისთვის — ძირითადად თარგმანი, ზოგჯერ ასევე ვალუტა, გამოსახულებები და იურიდიული ტექსტი.
- ლოკალი: ენა და, სურვილისამებრ, რეგიონი, მაგალითად
en-GBანpt-BR.
i18n ერთხელ გააკეთეთ და ყოველი ახალი ენის დამატება ძირითადად მხოლოდ თარგმნის სამუშაო გახდება.
ვარიანტები და კომპრომისები
| მიდგომა | როგორ მუშაობს | რისთვის არის კარგი | კომპრომისი |
|---|---|---|---|
| i18n ბიბლიოთეკა + თარგმანის ფაილები (მაგ. react-i18next, next-intl, vue-i18n) | ტექსტი თითო ლოკალის JSON ფაილშია; კომპონენტები გასაღებით ეძებენ მას | ყველაზე აპებისთვის | საწყისი რეფაქტორინგი და შესანარჩუნებელი თარგმანები |
| თარგმანის მართვის სისტემა (მაგ. Crowdin, Lokalise, Phrase) | ონლაინ რედაქტორი მთარგმნელებისთვის, თქვენს ფაილებთან სინქრონიზებული | ბევრი ენა და რამდენიმე მთარგმნელი | ფასიანია; კიდევ ერთი ინსტრუმენტი დასაყენებლად |
| მანქანური ან AI თარგმანი build-ის დროს | ავტომატური მონახაზის გენერაცია API-ით, შემდეგ გადახედვა | სწრაფად მიაღწიოთ ბევრ ენამდე | ხარისხის შემოწმება საჭიროა; API-ის ხარჯი |
| ბრაუზერის ან ვიჯეტის ავტომატური თარგმნა | ვიზიტორის ბრაუზერი გვერდს პირდაპირ თარგმნის | არაფერი, რაც თქვენ გააკონტროლოთ | ხარისხის კონტროლი არ არის; თარგმნილი გვერდები თქვენად არ ინდექსირდება |
| ცალკე საიტი თითო ენაზე | საიტის დუბლირება ბაზრის მიხედვით | ძალიან განსხვავებული ბაზრები | ყველაფერი ორჯერ უნდა შეინახოთ |
რიგითი აპისთვის საუკეთესო საფუძველია სტანდარტული i18n ბიბლიოთეკა თარგმანის ფაილებით. შეგიძლიათ მანქანური ან AI თარგმნით მონახაზი მოამზადოთ, შემდეგ კი მომხმარებლების მიერ ყველაზე ხშირად ნანახი ტექსტი ამ ენის მკითხველმა გადაამოწმოს.
მრავალენოვანი აპის ნაწილები
თარგმანის ფაილები
კოდში <h1>Welcome back</h1> აღარ წერია; წერია t('dashboard.welcome'), ხოლო თითოეულ ლოკალს აქვს ფაილი ტექსტით:
{
"dashboard": {
"welcome": "Welcome back, {{name}}",
"items_one": "{{count}} item",
"items_other": "{{count}} items"
}
}
ცვლადებისთვის გამოიყენეთ შემცვლელები და არა წინადადების ნაწილების შეერთება — სიტყვათა რიგი ენებს შორის განსხვავდება. ასევე გამოიყენეთ ბიბლიოთეკის მრავლობითი რიცხვის წესები: ინგლისურს ორი ფორმა აქვს (1 item, 2 items), ზოგ ენას კი სამი, ოთხი ან მეტი.
თარიღების, რიცხვების და ფულის ფორმატირება
ამათ ხელით ნუ აფორმატებთ. ბრაუზერის ჩაშენებული Intl API ნებისმიერი ლოკალისთვის ფორმატირებს: 1,234.5 ინგლისურად იწერება როგორც 1.234,5 გერმანულად; თარიღები დღე-თვე ან თვე-დღე თანმიმდევრობით იცვლება; ვალუტის სიმბოლო სხვა ადგილას დგას. თარიღები შეინახეთ UTC-ში, ფული კი რიცხვად კოდთან ერთად, და ფორმატირება მხოლოდ ჩვენებისთვის გააკეთეთ.
განლაგება, რომელიც იჭიმება
თარგმნილი ტექსტი ხშირად ინგლისურზე გრძელია — განსაკუთრებით გერმანულსა და ფინურში. თავი აარიდეთ ფიქსირებული სიგანის ღილაკებს და მოკვეთილ წარწერებს და ტესტი ყველაზე გრძელ ენაზე ჩაატარეთ.
მარჯვნიდან მარცხნივ ენები
არაბული, ებრაული, სპარსული და ურდუ მარჯვნიდან მარცხნივ იკითხება. ამ ლოკალებისთვის გვერდზე დააყენეთ dir="rtl" და გამოიყენეთ CSS ლოგიკური თვისებები (margin-inline-start margin-left-ის ნაცვლად; Tailwind-ში ms-4 ml-4-ის ნაცვლად), რომ განლაგება თავად დაირეკლოს. მიმართულების მაჩვენებელი ისრები კი შებრუნება უნდა.
ენის გადამრთველი და ამოცნობა
გადამრთველი ყველა გვერდზე იყოს, ენების სახელებით მათივე ენაზე („Deutsch“, „Français“, „العربية“), და არა დროშებით — დროშები ქვეყნებს წარმოადგენს და არა ენებს. ბრაუზერის სასურველი ენის ამოცნობა პირველ ვიზიტზე შეგიძლიათ შემოთავაზებისთვის გამოიყენოთ, მაგრამ ვიზიტორის მკაფიო არჩევანს უპირატესობა უნდა ჰქონდეს და უნდა დაიმახსოვროთ.
URL-ები და SEO
გვერდებისთვის, რომლებიც საძიებო შედეგებში უნდა ჩანდეს, თითოეულ ენას საკუთარი URL სჭირდება. 2026 წლის სექტემბრის მდგომარეობით, Google-ის რეკომენდაციები მრავალენოვანი საიტებისთვის ასეთია:
- ცალკე URL თითო ენისთვის — ყველაზე მარტივია ქვედირექტორიები (
example.com/fr/); ქვედომენები და ქვეყნის დომენებიც მუშაობს. URL პარამეტრები (?lang=fr) არ არის რეკომენდებული. - ენა მხოლოდ cookie-ით ან ბრაუზერის პარამეტრით არ შეცვალოთ — Google-ის მკვლევარმა შესაძლოა სხვა ვერსიები ვერასდროს ნახოს.
- ენის მიხედვით ავტომატურად არ გადაამისამართოთ — მის ნაცვლად ვერსიები ერთმანეთს დააკავშირეთ.
- გამოიყენეთ hreflang, რომ Google-ს ეთქვათ, რომელი გვერდები წარმოადგენს ერთმანეთის თარგმანს. თითოეულმა ვერსიამ უნდა მიუთითოს საკუთარი თავი და ყველა დანარჩენი, წინააღმდეგ შემთხვევაში ანოტაციები შეიძლება უგულებელყოფილი იყოს. ხარვეზის მიმღები გვერდისთვის დაამატეთ
x-default. - Google გვერდის ენას ხილული შინაარსით ამოიცნობს და არა
lang-ით ან hreflang-ით — ამიტომ თარგმნეთ მთელი გვერდი და არა მხოლოდ მენიუ.
მაინც დააყენეთ <html lang="fr"> ყოველ ვერსიაზე: ეკრანის მკითხველები მას იყენებენ სწორი გამოთქმის ასარჩევად, და ეს ხელმისაწვდომობის მოთხოვნაა.
აპის შიდა, შესული მომხმარებლის ეკრანებს ინდექსირება არ სჭირდება, ასე რომ მათთვის ენის შენახვა მომხმარებლის პროფილში საკმარისია. იხილეთ SEO AI-ით აგებული ვებსაიტებისთვის, რათა საჯარო გვერდები საერთოდ დაინდექსირდეს.
კონტენტი მონაცემთა ბაზაში
ინტერფეისის ტექსტი ფაილებში ინახება; კონტენტი, როგორიცაა პროდუქტის სახელები, ბლოგის პოსტები და კატეგორიები, — მონაცემთა ბაზაში. ორი გავრცელებული მიდგომა არსებობს:
- თარგმანების ცხრილი:
product_translations (product_id, locale, name, description). სუფთაა და ბევრ ენაზე მასშტაბირდება. - JSON სვეტი თითო ველისთვის:
name: {"en": "...", "fr": "..."}. რამდენიმე ენისთვის უფრო მარტივია.
გადაწყვიტეთ, რა მოხდება, თუ თარგმანი არ არსებობს — ჩვეულებრივ უნდა დაბრუნდეთ ნაგულისხმევ ენაზე და არა ცარიელი ადგილი ჩანდეს.
ელფოსტები და შეტყობინებები
შეინახეთ თითოეული მომხმარებლის ენა და გამოიყენეთ ის ელფოსტებში, შეტყობინებებსა და PDF-ებშიც. ადვილია აპის თარგმნა და იმის დავიწყება, რომ მისასალმებელი წერილი მაინც ინგლისურად მოდის.
პრომპტები, რომლებიც მუშაობს
დაამატე internationalisation react-i18next-ით. გადაიტანე ყველა მომხმარებლისთვის ხილული სტრიქონი locales/en.json-ში სახელთა სივრცის მქონე გასაღებებით, გამოიყენე ცვლადები და მრავლობითი რიცხვის წესები სტრიქონების შეერთების ნაცვლად, და თარიღები, რიცხვები და ფასები დააფორმატე Intl-ით მიმდინარე ლოკალის მიხედვით. ჯერ არაფერი შეცვალო ტექსტში.
დაამატე ფრანგული და გერმანული. საჯარო მარკეტინგულ გვერდებს მიეცეს /fr/ და /de/ URL პრეფიქსები, ინგლისური დარჩეს ფესვში, ყველა გვერდზე იყოს hreflang ბმულები (თვითმითითებითა და x-default-ით), და თითო გვერდზე დაყენდეს html lang. დაამატე ენის გადამრთველი, რომელიც თითოეული ენის საკუთარ სახელს აჩვენებს. შესულ გვერდებზე ენა შეინახე მომხმარებლის პროფილში.
დაამატე არაბული მარჯვნიდან მარცხნივ მხარდაჭერით: არაბულისთვის დააყენე dir="rtl", მარჯვენა და მარცხენა მარგინებისა და პადინგების ნაცვლად გამოიყენე ლოგიკური თვისებები, მიმართულების მაჩვენებელი ისრები დააბრუნე, და შეამოწმე, რომ ფორმები და ცხრილები მაინც სწორად იკითხება.
ნაბიჯ-ნაბიჯ
- აირჩიეთ პირველი დამატებითი ენა რეალური მოთხოვნის მიხედვით — სად არიან თქვენი ვიზიტორები ან მომხმარებლები.
- დააყენეთ i18n კოდში: გადაიტანეთ ტექსტი ფაილებში, დაამატეთ მრავლობითი რიცხვი და
Intlფორმატირება. გამოუშვით მხოლოდ ინგლისურით და შეამოწმეთ, რომ არაფერი შეცვლილა. - განსაზღვრეთ URL სტრუქტურა საჯარო გვერდებისთვის და დაამატეთ hreflang.
- თარგმნეთ: მონახაზი გააკეთეთ მანქანური ან AI თარგმნით, შემდეგ გადახედეთ ენის მკითხველს. მიაწოდეთ მთარგმნელებს კონტექსტი — სიტყვა „Book“ ერთ ეკრანზე არსებითი სახელია, მეორეზე ზმნა.
- თარგმნეთ მონაცემთა ბაზის კონტენტი და დააყენეთ სარეზერვო ვარიანტები.
- მოარგეთ დანარჩენიც: ელფოსტები, შეცდომის შეტყობინებები, იურიდიული გვერდები, სურათები ტექსტით.
- შეამოწმეთ ყოველი ენა ტელეფონის სიგანეზე, და მარჯვნიდან მარცხნივ ენისთვის — ამ წესითაც.
- დააწესეთ პროცესი, რომ ახალი ფუნქციები თარგმანებით გამოიშვას და არა თვეების შემდეგ.
გავრცელებული შეცდომები
- წინადადებების შეერთება (
"You have " + n + " messages"), რაც სხვა ენებზე ირღვევა. - კომპონენტებში დატოვებული ხისტი ტექსტი, შეცდომის შეტყობინებები და ვალიდაციის სტრიქონები.
- თარიღებისა და ფასების ხელით ფორმატირება.
- დროშები ენების სიმბოლოდ და ავტომატური გადამისამართებები, რომლებიც ადამიანს არასწორ ვერსიაში ტოვებს.
- ერთი URL ყველა ენისთვის იმ გვერდებზე, რომლებიც უნდა დაინდექსირდეს.
- დაკარგული hreflang დაბრუნების ბმულები, რის გამოც Google ანოტაციებს უგულებელყოფს.
- ინტერფეისის თარგმნა კონტენტის გარეშე ან პირიქით.
- გადაუმოწმებელი მანქანური თარგმანი ფასების, იურიდიულ და გადახდის გვერდებზე.
მრავალენოვანი აპის ჩამონათვალი
- ხისტი, მომხმარებლისთვის ხილული ტექსტი არ არის; გამოყენებულია მრავლობითი რიცხვის წესები და შემცვლელები
- თარიღები, რიცხვები და ვალუტები ფორმატირდება
Intl-ით - ენის გადამრთველი ყველა გვერდზე, ენების საკუთარი სახელებით; არჩევანი დამახსოვრებულია
- საჯარო გვერდებისთვის ცალკე URL თითო ენაზე; იძულებითი გადამისამართება არ არის
- hreflang ყოველ ვერსიაზე, მათ შორის თვითმითითებითა და x-default-ით
-
html lang(და სჭირდებისამებრdir="rtl") თითო გვერდზე დაყენებული - მონაცემთა ბაზის კონტენტი ითარგმნა, სარეზერვო ვარიანტებით
- ელფოსტები და შეტყობინებები იგზავნება მომხმარებლის ენაზე
- მომხმარებლისთვის განკუთვნილი ტექსტი გადახედა ენის მკითხველმა
მრავალი ენა Mythex-ზე
Mythex-ზე ენებს ჩატში ითხოვთ — ცალკე სათარგმნი პანელი არ არსებობს — ამიტომ ზემოთ მოცემული პრომპტები ისე მუშაობს, როგორც წერია. ჯერ გააკეთეთ internationalisation და შეამოწმეთ Preview-ში ენების დამატებამდე; ეს დიდი რეფაქტორინგია, და ჩატის checkpoint გაძლევთ წერტილს, სადაც შეგიძლიათ დაბრუნდეთ, თუ რამე გატყდა (ჩატი და checkpoint-ები). თუ გსურთ, რომ აპი კონტენტს ავტომატურად თარგმნიდეს AI-ით ან თარგმანის API-ით, ეს იყენებს თქვენს საკუთარ API გასაღებს, რომელიც პროექტის პარამეტრებში ინახება (გარემოს ცვლადები და საიდუმლოებები); ხარჯებს LLM API-ების გამოყენების გზამკვლევი ხსნის. ახალი ენები მზად რომ იყოს, კვლავ გამოაქვეყნეთ.
კითხვები
რა განსხვავებაა i18n-სა და ლოკალიზაციას შორის?
ინტერნაციონალიზაცია (i18n) არის კოდის მომზადება, რომ მან ბევრი ენა მხარი დაუჭიროს: ტექსტი კოდში ხისტად არ წერია, თარიღები და რიცხვები ადგილობრივი ფორმატით იწერება, განლაგება კი გრძელ სიტყვებსა და მარჯვნიდან მარცხნივ ენებსაც უძლებს. ლოკალიზაცია (l10n) არის კონკრეტული ენის ან ბაზრისთვის მორგება, უპირველეს ყოვლისა თარგმანი.
შემიძლია უბრალოდ მანქანური თარგმანი ან AI გამოვიყენო აპის თარგმნისთვის?
პირველი ვარიანტისთვის — დიახ. თანამედროვე მანქანური და AI თარგმანი კარგად უძლებს ინტერფეისის ტექსტს. მომხმარებლისთვის განკუთვნილი ყველაფერი მაინც უნდა გადახედოს ამ ენის მკითხველმა, განსაკუთრებით იურიდიული ტექსტი, ფასები და მარკეტინგული მასალა, რადგან ტონი და წვრილი შეცდომები აქ მნიშვნელოვანია.
თითოეულ ენას საკუთარი URL უნდა ჰქონდეს?
საჯარო გვერდებისთვის, რომლებიც საძიებო შედეგებში უნდა გამოჩნდეს — დიახ. Google გვირჩევს ცალკე URL-ებს თითო ენისთვის, მაგალითად /fr/ და /de/, და არა ენის შეცვლას cookie-ით ან ბრაუზერის პარამეტრით, რადგან მისმა მკვლევარმა შესაძლოა მხოლოდ ერთი ვერსია ნახოს.
უნდა გადავამისამართო ვიზიტორები ბრაუზერის ენის მიხედვით?
შემოგვთავაზეთ, არ აიძულოთ. Google არ ურჩევს ავტომატურ ენობრივ გადამისამართებას, რადგან მან შეიძლება ადამიანები და მძებნელი რობოტები სხვა ვერსიებამდე არ მიიყვანოს. აჩვენეთ მცირე შეტყობინება შესაბამისი ენის შეთავაზებით და ხილული გადამრთველი ყველა გვერდზე.