Trikoder se suočio s izazovom uvođenja postojeće hrvatske platforme njuskalo.hr na novo tržište sa sjedištem u Sloveniji (bolha.com). Trebalo je razviti podršku za novu valutu, jezik i mogućnosti plaćanja

Trikoder, partner .debuga, developerska je tvrtka koja je zaslužna za tehnološka rješenja koja stoje iza najvećeg domaćeg internetskog oglasnika, Njuškala. Svoju su tehnologiju nedavno prilagodili i za drugo tržište, pa su ovaj proces detaljno opisali za nas i naše čitatelje…

Ukoštac s izazovima

Budući da smo Njuškalo aktivno razvijali više od 10 godina, možete zamisliti kakvo je bilo stanje codebase-a u to vrijeme: sve puno hardkodiranih statičkih tekstova, hardkodiranih vrijednosti valuta, funkcionalnosti za čije isključivanje na jednom tržištu vam treba kristalna kugla i slično. Kad smo zasukali rukave, ideja je bila da napravimo jedinstveni repozitorij za oba tržišta i upravljamo razlikama poput jezika, korištene valute i promjenjivih funkcionalnosti putem konfiguracijskih datoteka.

Ovaj bi pristup osigurao lakši razvoj i održavanje za oba tržišta u budućnosti, uključivanje ili isključivanje funkcionalnosti ovisno o zahtjevima poslovnog odjela i, naposljetku, lakši izlazak na nova tržišta. Evo nekih izazova s kojima smo se suočili i kako smo ih riješili.

Prijevodi

Morali smo pregledati cijeli postojeći codebase s više od 20.000 datoteka, pronaći i zamijeniti sve statičke tekstualne sadržaje na hrvatskom jeziku sa pozivima na funkcije za dinamičke prijevode. To je bio ogroman posao na kojem je više od 5 mjeseci radio tim naših mlađih programera.

Ukupno 18.000 tekstova za prijevod je bilo indentificirano i izdvojeno u .po datoteke. Datoteke GetText Portable Object (PO) industrijski su standard za višejezične web stranice u PHP-u. Napisane su u lako čitljivom formatu, tako da ih mogu uređivati programeri i prevoditelji koji su nam dostavljali prijevode za slovensko tržište. Symfonyjeva komponenta za prijevod korištena je za prijevod sadržaja u backendu. 

Dio tih 18.000 prijevoda trebao je biti dostupan JavaScript datotekama u frontend dijelu sustava. Servis za učitavanje podskupova prevedenih tekstova implementiran je u backendu kako bi se frontendu pružili samo oni prijevodi koji su potrebni za određeni tip stranice. Interno razvijeni modul Translate JS korišten je za prikazivanje prijevoda u našem frontendu temeljenom na Figura i Vue tehnologijama.

Lokalizacija rute

Morali smo internacionalizirati svoje rute za novo tržište. Budući da smo u to vrijeme bili na Symfonyju 3.4 koji nije pružao ovu funkcionalnost, morali smo potražiti alternative. Pronašli smo nekoliko besplatnih open source komponenata, ali kako smo znali da Symfony 4.1 ima podršku za ovu funkcionalnost (i znali smo da u budućnosti planiramo prelazak na Symfony 4.4), odlučili smo privremeno omogućiti backport podršku za internacionalizaciju sa Symfonyja 4 našem 3.4 projektu (umjesto da u tu svrhu koristimo open source komponente).

Nakon nadogradnje na Symfony 4.4 ove godine uspješno smo samo izbrisali taj kod i sve je nastavilo raditi. Dio tog napora internacionalizacije ruta bio je i premještanje definicija ruta i generiranja URL-ova sa našeg internog frameworka na Symfony kako bismo imali jedan središnji alat koji bi upravljao rutama (Symfony).

Dio novih lokaliziranih ruta morali smo koristiti i na frontend dijelu sustava gdje se routing odvija na klijentu (Vue ruter). Željeli smo zadržati definicije ruta i lokalizacije u jednoj tehnologiji (backendu) – pa je na backendu implemetiran servis za učitavanje podskupa routing pravila u frontend kako bi router na klijentu također raspolagao i upravljao sa lokaliziranim rutama.

Lokalizacija teme i kategorija

Od početka smo znali da će Bolha morati imati drukčiju kombinaciju boja, grafika i stilova nego na Njuškalu. Stoga smo morali proširiti svoju tehnologiju kako bismo omogućili tu prilagodbu.

Razvili smo sustav za teme kako bismo svakoj od instanci omogućili različite stilove i opći “izgled i dojam”. Svaka instanca CBT-a (Common based tehnologija) ima jednu temu koja je određena konfiguracijom instance. Kada se u backend ili frontend dijelu koda referira na frontend resurs, on prolazi kroz naš algoritam pretraživanja i procesiranje resursa. Kada se pripremaju stilovi (CSS) za instancu putem webpacka / SASS procesora, na osnovu varijabli i stilova definiranih za odabranu temu generiraju se optimizirane datoteke namijenjene internet preglednicima. Frontend resursi čiji konačan oblik i reprezentacija zavisi o uključenoj temi i konfiguraciji instance tehnički su temelji jednostavnog i moćnog tematskog sustava.

Lokalizacija valute

Prije početka projekta imali smo hardkodiranu hrvatsku valutu (HRK) kao primarnu valutu i euro (EUR) kao sekundarnu valutu po cijelom codebaseu. I ne samo to, nego smo u codebaseu imali najmanje pet različitih formatera za ispis cijena, koji su svi formatirali cijene na drugi način prije prikazivanja korisniku. To se moralo promijeniti i morali smo se s poslovnim odjelom dogovoriti jedinstveni način formatiranja cijena na platformi, ovisno o tržištu. To nije bio lak podvig jer je financijski odjel želio da se to učini na jedan način, odjel za korisničku podršku na drugi itd. Na kraju smo se odlučili za jedan standard s nekoliko manjih varijacija, ovisno o tome prikazuje li se cijena na javnom dijelu ili administrativnom dijelu web stranice.

Nakon što smo izvršili početnu implementaciju, naš je hosting provider ažurirao našu PHP verziju sa 7.2.15 na 7.2.16, a output formatera cijena se promijenio. Naša je istraga pokazala da je ekstenzija PHP intl sada spojena s novijom verzijom libICU-a (ažuriranom za gotovo deset glavnih verzija), koja je usto imala u paketu noviju bazu podataka Unicode CLDR.
Zato smo morali poboljšati našu implementaciju i dati joj mogućnost forsiranja nekih mogućnosti formatiranja (poput razmaka, položaja simbola za valutu i izgleda simbola za valutu – na primjer u PHP intl ekstenzijki simbol za hrvatsku kunu promijenio se iz “kn” u “HRK”) kako ne bi postala ovisna o verzijama PHP intl / libICU na kojima se aplikacija izvodi.

Konfigurabilne funkcionalnosti i parametri instanci

Zajedničkim naporima naših backend i frontend programera izgrađen je sustav u kojem su parametri konfiguracije instance definirani na backendu transparentno dostupne i frontendu. Podskup parametara kompajlira se na backendu u JSON datoteku koja je dostupna i build procesu frontenda. Izlazne CSS i JavaScript datoteke stoga su prilagođene i automatski optimizirane za svaku instancu na temelju njene konfiguracije. U backendu se funkcionalnosti mogu uključiti ili isključiti u konfiguraciji koja je postignuta korištenjem paketa Flagception.