პროგრამული პროდუქტი, იქნება ეს დესკტოპ აპლიკაცია, SaaS პლატფორმა, ERP სისტემა თუ ტექნიკური ინსტრუმენტი, მომხმარებელთან ათასობით სტრიქონით საუბრობს: მენიუებით, დიალოგებით, შეცდომის კოდებით, ლოგებით, ტოლტიპებით, დახმარების სტატიებით. თუ ეს ხმა არათანმიმდევრულია, ერთ ეკრანზე "Export" ხდება "ექსპორტი", მეორეზე "გატანა", მესამეზე კი საერთოდ ინგლისურად რჩება, მომხმარებელი პროდუქტს არასანდოდ აღიქვამს და მხარდაჭერის განყოფილება ზედმეტი შეკითხვების ნაკადს იღებს. პროგრამული უზრუნველყოფის ლოკალიზაცია (software localization, L10n) სწორედ ამ თანმიმდევრულობასა და ტექნიკურ სიზუსტეს უზრუნველყოფს.
ინტერნაციონალიზაცია და ლოკალიზაცია: ორი ეტაპი, ერთი მიზანი
პროფესიულ პრაქტიკაში ორი ცნება ერთმანეთს ავსებს:
- ინტერნაციონალიზაცია (i18n) დეველოპერის ამოცანაა: კოდი ისე უნდა იყოს აგებული, რომ ტექსტი კოდისგან განცალკევებულ რესურს ფაილებში ინახებოდეს, თარიღები და რიცხვები სისტემური ლოკალის მიხედვით ფორმატდებოდეს, ინტერფეისი კი ტექსტის სიგრძის ცვლილებას უძლებდეს.
- ლოკალიზაცია (L10n) ჩვენი ამოცანაა: ამ რესურს ფაილების ენობრივი, კულტურული და ტექნიკური ადაპტაცია კონკრეტული ბაზრისთვის.
თუ პროდუქტი ინტერნაციონალიზაციის გარეშეა შექმნილი (ტექსტი კოდში პირდაპირ არის ჩაწერილი, სტრიქონები რამდენიმე ნაწილისგან იკვრება), ლოკალიზაცია რთული და არასაიმედო ხდება. ამიტომ პროექტის დასაწყისში ტექნიკურ აუდიტს ვატარებთ და დეველოპერ გუნდს კონკრეტულ რეკომენდაციებს ვაძლევთ, სანამ თარგმნას დავიწყებთ.
რას მოიცავს პროგრამული უზრუნველყოფის ლოკალიზაცია
- ინტერფეისის სტრიქონები: მენიუ, ღილაკები, დიალოგები, პარამეტრების პანელი, სტატუსის ზოლი, კონტექსტური მენიუ, კლავიატურის მალსახმობების აღწერილობა.
- შეცდომების და სისტემური შეტყობინებები: შეცდომის კოდები, გაფრთხილებები, ლოგის ჩანაწერები, რომლებიც ხშირად ტექნიკური მხარდაჭერისთვისაც უნდა იყოს ცალსახად იდენტიფიცირებადი.
- ინსტალატორი და ლიცენზია: ინსტალაციის ოსტატი, ლიცენზიის შეთანხმება (EULA), განახლების შეტყობინებები.
- დახმარების სისტემა და დოკუმენტაცია: მომხმარებლის სახელმძღვანელო, ონლაინ დახმარების ცენტრი, ცოდნის ბაზა, ვიდეო გაკვეთილების სუბტიტრები, ტექნიკური სპეციფიკაციები.
- API და დეველოპერული დოკუმენტაცია: სადაც ლოკალიზდება განმარტებითი ტექსტი, კოდის მაგალითები კი უცვლელი რჩება.
- სასწავლო და მარკეტინგული მასალები: პროდუქტის ტურები, onboarding ელფოსტები, გამოშვების შენიშვნები (release notes).
სტრიქონული რესურსები: სად იმალება ტექნიკური რისკები
პროგრამული სტრიქონი იშვიათად არის "უბრალო წინადადება". ტიპური რესურს ფაილი შეიცავს:
- ცვლადებსა და placeholder-ებს: `%s`, `%d`, `{0}`, `{{name}}`, `${count}`. თითოეული უცვლელად უნდა დარჩეს და წინადადებაში გრამატიკულად სწორ ადგილას მოხვდეს.
- მრავლობითის წესებს: ICU MessageFormat, .stringsdict, Android plurals. ქართული, რუსული, პოლონური და არაბული ერთმანეთისგან რადიკალურად განსხვავებულ ლოგიკას იყენებს.
- მალსახმობებსა და ამპერსანდებს: Windows აპლიკაციებში "&File" ნიშნავს, რომ F ასო Alt კომბინაციით აქტიურდება. ლოკალიზებულ მენიუში ეს ასოები არ უნდა მეორდებოდეს.
- HTML და Markdown ფრაგმენტებს: სტრიქონები ხშირად შეიცავს ბმულებს, გამუქებულ ტექსტს, სტრიქონის გადატანის სიმბოლოებს.
- კონკატენაციას: როცა წინადადება რამდენიმე სტრიქონისგან იკვრება ("You have" + count + "new messages"), სამიზნე ენაზე სიტყვათა რიგი შესაძლოა ვერ დაემთხვეს. ასეთ შემთხვევებს ვაფიქსირებთ და დეველოპერს სტრიქონის გაერთიანებას ვურჩევთ.
- კომენტარებსა და კონტექსტს: `msgctxt`, developer comments, ეკრანის ანაბეჭდები. "Open" შეიძლება იყოს ზმნა (გახსნა) ან ზედსართავი (ღია), და კონტექსტის გარეშე არჩევანი გამოცნობაზეა დამოკიდებული.
ჩვენი CAT ინსტრუმენტები ცვლადებსა და თეგებს ავტომატურად იცავს, ხოლო QA მოდული ყოველ სტრიქონს ამოწმებს ცვლადის დაკარგვაზე, დუბლირებაზე, სიგრძის ლიმიტის გადაჭარბებაზე და ტერმინოლოგიური ბაზიდან გადახვევაზე.
ფაილის ფორმატები, რომლებთანაც ვმუშაობთ
- .NET: .resx, .resw
- Java: .properties, ResourceBundle
- Windows: .rc, .dll რესურსები, WiX ინსტალატორის ფაილები
- macOS და iOS: .strings, .stringsdict, .xcstrings
- Qt: .ts ფაილები
- GNU: PO/POT (gettext)
- ვებ და კროსპლატფორმული: JSON, YAML, XLIFF 1.2 და 2.0, ARB, TOML
- დოკუმენტაცია: Markdown, DITA, DocBook, HTML, AsciiDoc, Confluence ექსპორტი
- პლატფორმები: Crowdin, Lokalise, Phrase, Transifex, Weblate, ასევე Git რეპოზიტორიასთან პირდაპირი ინტეგრაცია და CI/CD პროცესში ჩართვა
ფაილს იმავე სტრუქტურით ვაბრუნებთ, კოდირების (UTF-8) და სტრიქონების გადატანის (LF/CRLF) სტილის შენარჩუნებით, ასე რომ თარგმანი პირდაპირ build პროცესში მიდის.
ტერმინოლოგიის მართვა: პროდუქტის ენა, რომელიც არ იცვლება
პროგრამული პროდუქტი წლების განმავლობაში ვითარდება, ხშირად სხვადასხვა გუნდის ხელით. თანმიმდევრულობის ერთადერთი გარანტია ცენტრალიზებული ტერმინთა ბაზა და მთარგმნელობითი მეხსიერება:
- გლოსარიუმი აფიქსირებს პროდუქტის ყოველ საკვანძო ტერმინს, მის დამტკიცებულ თარგმანს, განმარტებასა და აკრძალულ ვარიანტებს. მაგალითად: "workspace" = "სამუშაო სივრცე", არა "ვორქსფეისი" და არა "სამუშაო ადგილი".
- სტილის სახელმძღვანელო ადგენს მიმართვის ფორმას (თქვენ/შენ), ზმნის ფორმას ღილაკებზე (ბრძანებითი: "შენახვა" თუ საწყისი: "შეინახეთ"), პუნქტუაციასა და დიდი ასოს გამოყენებას.
- მთარგმნელობითი მეხსიერება უზრუნველყოფს, რომ ერთხელ დამტკიცებული სტრიქონი ყოველ განახლებაში ავტომატურად იმეორებს თავს, რაც ვადებს ამცირებს: ტიპურ განახლებაში ახალი სტრიქონები მთელი მოცულობის 5-15%-ია.
ლინგვისტური და ფუნქციური ტესტირება
მზა რესურს ფაილი პროდუქტში ჩაშენების შემდეგ ტესტირებას გადის:
- ლინგვისტური QA: ტესტერი ლოკალიზებულ build-ს რეალურ გარემოში (Windows, macOS, ბრაუზერი) გადის და ამოწმებს დაჭრილ ტექსტს, არასწორ კონტექსტში მოხვედრილ სტრიქონს, არათარგმნილ ელემენტებს, კოდირების პრობლემებს.
- ფუნქციური QA: ლოკალიზებული ვერსიის ქცევა ორიგინალისგან არ განსხვავდება: მალსახმობები მუშაობს, ფორმატები სისტემურ ლოკალს ემთხვევა, დახარისხება ქართული ანბანის მიხედვით ხდება, ველები ქართულ სიმბოლოებს იღებს.
- რეგრესია განახლებისას: ყოველ ახალ ვერსიაში მხოლოდ შეცვლილი და ახალი სტრიქონები მოწმდება, რაც პროცესს სწრაფს ხდის.
ყოველი პრობლემა სტრიქონის იდენტიფიკატორით, ეკრანის ანაბეჭდითა და შემოთავაზებული გამოსწორებით ფიქსირდება, რათა დეველოპერს დამატებითი ძიება არ დასჭირდეს.
უწყვეტი ლოკალიზაცია აგილურ გუნდებში
თანამედროვე პროდუქტები ორკვირიან სპრინტებში ან უფრო ხშირადაც გამოდის. ლოკალიზაცია ამ რიტმს უნდა მიჰყვებოდეს, არა აფერხებდეს. უწყვეტი ლოკალიზაციის (continuous localization) მოდელში ახალი სტრიქონები რეპოზიტორიიდან ავტომატურად მიდის ლოკალიზაციის პლატფორმაზე, ჩვენი გუნდი მათ 1-2 სამუშაო დღეში ამუშავებს, თარგმანი კი pull request-ის სახით ბრუნდება. შედეგად ყოველი გამოშვება ყველა ენაზე ერთდროულად ხდება, ხოლო "ჯერ ინგლისურად გავუშვათ, ქართული მერე" პრაქტიკა, რომელიც ადგილობრივ მომხმარებელს მეორეხარისხოვნად აგრძნობინებს, აღარ არის საჭირო.
ხშირად დასმული კითხვები
რა განსხვავებაა ინტერნაციონალიზაციასა და ლოკალიზაციას შორის?
ინტერნაციონალიზაცია (i18n) კოდის მომზადებაა მრავალენოვანი მუშაობისთვის და დეველოპერის ამოცანაა. ლოკალიზაცია (L10n) რესურს ფაილების ადაპტაციაა კონკრეტული ენისა და ბაზრისთვის. პროექტის დასაწყისში ვამოწმებთ, რამდენად მზადაა კოდი ლოკალიზაციისთვის, და საჭირო რეკომენდაციებს ვაძლევთ.
შეგიძლიათ მუშაობა უშუალოდ ჩვენს რეპოზიტორიასთან?
დიახ. ვმუშაობთ Git ინტეგრაციით ლოკალიზაციის პლატფორმების (Crowdin, Lokalise, Phrase, Weblate) მეშვეობით ან პირდაპირ pull request-ებით, რაც ლოკალიზაციას თქვენს CI/CD პროცესში აერთიანებს.
როგორ უზრუნველყოფთ, რომ ცვლადები და კოდი არ დაზიანდეს?
CAT ინსტრუმენტები ცვლადებსა და თეგებს დაცულ ელემენტებად აღიქვამს, ხოლო ავტომატური QA ყოველ სტრიქონს ამოწმებს ცვლადის დაკარგვაზე ან დამახინჯებაზე. დამატებით ლოკალიზებული build ფუნქციურ ტესტირებას გადის.
ლოკალიზებთ თუ არა ტექნიკურ დოკუმენტაციასა და დახმარების ცენტრს?
დიახ. მომხმარებლის სახელმძღვანელო, ცოდნის ბაზა, API დოკუმენტაცია და release notes იმავე ტერმინთა ბაზით ლოკალიზდება, რაც ინტერფეისი, ასე რომ მომხმარებელი დახმარების სტატიაში ზუსტად იმ ტერმინებს ხედავს, რასაც ეკრანზე.
რამდენ ხანში ლოკალიზდება ახალი გამოშვება?
უწყვეტი ლოკალიზაციის მოდელში ტიპური სპრინტის სტრიქონები (რამდენიმე ასეული სიტყვა) 1-2 სამუშაო დღეში მზადდება, ტესტირების ჩათვლით. მსხვილი პირველადი ლოკალიზაცია ეტაპობრივად იგეგმება და ვადას ტექნიკური აუდიტის შემდეგ ვასახელებთ.