შეჯამება
წინა თავებში განვიხილეთ ორი მიდოგმა, ანგულარის მიერ შემოთავაზებული მიდგომა და third-party პაკეტი ngx-translate.
მსგავსი დანიშნულებისთვის არსებობს კიდევ სხვა third-party პაკეტეტები, რომელთა განხილვაც შეიძლება თუმცა ყველაზე პოპულარული არის ngx-translate.
ორივე მიდგომას გააჩნია თავისი უარყოფითი და დადებითი მხარეები, მოდით განვიხილოთ ისინი:
დადებითი მხარე ანგულარის შემოთავაზებულ პაკეტში ის არის, რომ პირდაპირ ანგულარის გუნდის მიერ არის შემოთავაზებული და უსაფრთხოების მხრივ უფრო დაცული პაკეტია.
ხშირ შემთხვევაში მომხარებელს მხოლოდ ერთი ენის აპლიკაციის გამოყენება სჭირდება და არა რეალურ დროში რამდენიმეჯერ ცვლილება. რაც საშალებას გვაძლევს, რომ აპლიკაცია წინასწარ ვთარგმნოთ და რესურსები დავზოგოთ. მიუხედავად ამისა არის მომენტი როცა მომხარებელს სჭირდება ენის ხშირად ცვლილება, ამ შემთხვევაში ჩვენი ვებგვერდი უნდა დარეფრეშდეს და გადავიდეს სხვა მისამართზე, რაც რეალუარდ არ არის იდეალური მიდგომა მომხარებლისათვის. სწორედ ასეთი შემთხვევების გამოიყენება ngx-translate, რაც გვაძლევს შესაძლებლობას, რომ რეალურ დროში ვცვალოთ ენები მარტივად, ბევრი კოდის წერის გარეშე. ანგულარის ჩაშენებულ i18n-ის ერთ-ერთი მინუსი არის ბევრი boilerplate კოდი, ამიტომ ბევრი ეტაპის გავლა გვიწევს სასურველი შედეგის მისაღებად. როცა განვიხილავდით მის გამოყენებას, არ აღვნიშნეთ, რომ შესაძლებელია json გაფართოვების გამოყენება ლოკალის ფაილებისთვის.
თუმცა უშუალოდ როცა დაგჭირდებათ კოდის ატვირთვა და სხვადასხვა დეტალების გაზიარება ორი ვებგვერდისთვის, ისევ დამატებითი მუშაობა დაგვჭირდება მსგავსი ტიპის ენის ცვლილების გამო. ngx-transalte-დან გამომდინარე ენა იცვლება პირდაპირ იმავე ვებგვერდზე და არ საჭიროებს მის გადაყვანას, თუმცა ngx-translate საც გააჩნია უარყოფითი მხარეები:
- თუ ბევრი თარგმანი და ენების ლოკალის ფაილები მოგვიგროვდება, ის ამძიმებს ჩვენს აპლიკაციას მცირედად.
- შესაძლოა
ngx-translateდეველოპერებმა შეწყვიტოს პაკეტის განახლება.
ამგვარად წინა თავებში განხილული შედეგებიდან ვიხილეთ თუ როგორი სახითაც შეგვიძლია ინტერნაციონალიზაციის დამატება ანგუალრში, რომელ მეთოდს გამოიყენებთ ეს თქვენზეა დამოკიდებული და თქვენს აპლიკაციაზე.