Localising MakeMyTrip’s Flights Funnel Content (The Multilingual Project)
Envisioning Multilingual:
We saw it coming around 1.5 years ago, after stabilising the ClientBackend layer of Flights funnel. ClientBackend layer, which is based on Backend-For-Frontend architecture, fetches the flight funnel data from the downstream layers and then formats it to display on the various UI clients. We realised that a lot of formatting and polishing business logic was getting written on this layer, which needed a lot of messages (i.e. strings) to be kept with the ClientBackend code! Seeing a lot of strings hardcoded and being manipulated in the code, we decided to opt for a better code design which could support localisation as well in the future.
Planning Multilingual:
After analysing thousands of strings in the ClientBackend code and some exported monolithic configurations, we decided to change them! As an initial step to achieve Multilingual, we decoupled the hard-coded strings/messages from the ClientBackend code, removed all the string manipulations and then restructured the monolithic configuration file into context-wise sub-files to support different language dictionaries. We wanted to proactively keep the ClientBackend code localisation friendly, hence we right-away added these items to our tech debt list and allotted bandwidth to solve this. In the coming months we had our code ready with Multilingual pre-requisites.
Multilingual As A Project:
At the same time when we were handling the pre-requisites of Multilingual, MMT was going live in the USA and UAE regions. Soon after going live, product team came up with the requirement of supporting Arabic on MMT website in AE region. At this time we were proud that we had foreseen this a few months back and had already completed the initial changes.
Designing Multilingual Framework:
A team was setup for creating a translation engine called Polyglot, which was consumable by different services like ClientBackend to fetch translations for its messages file. Now the challenge was that Polyglot service required Message-Ids for the uploaded messages but we had kept all the messages mapped with Consul keys, hence to solve this, we added a two-level lookup in configurations, keeping messages mapped with message Ids in messages files and those message Ids were then configured in Consul configuration to use at ClientBackend. For CRUDing English messages, we utilised our in-house HQ tool. Upon translation, localised message files would be created/updated and the same would be loaded in the ClientBackend memory during boot up. Similar to messages, we localised the other JSON files as well like Airport, Airline, Errors etc. which were being used for preparing UI textual content.
Maintaining English messages at ClientBackend made sure that we always had English backup.So we were dependent on Polyglot only for the other languages, which was anyway an asynchronous operation.
Apart from above, we faced another challenge: preparing & manipulating dynamic messages in context with the runtime language (for e.g. in Right-To-Left languages, placement of variables could differ as compared to English), which we solved by introducing templatized messages, which use placeholders for the dynamic parts of the messages. In translated messages, these placeholders could be placed accordingly by the content moderators, following their language context. We made these templatized messages flow along with the replace-data across the flights funnel, as dynamic messages were being created at many layers.
Going Live With Multilingual:
We finally went live with Multilingual support on MMT Flights funnel. The best part was that any language could be added into the configurations and it would start showing up on the UI! In-fact, we demonstrated this capability by onboarding three regional Indian languages within half-an-hour. Of course, creating a framework is a one-time thing but adapting according to it is a long term responsibility, so for every new feature/content, we are taking best care to educate our new team members to keep following the localisation checklist in Flights funnel.
What Next:
There are still some things that we left for Phase-II, for example accepting user inputs in any local language, this could not be done at that point of time due to the limitation that airlines supported only English language as input. Also, currently, we need human moderators for finalising the multilingual content, once we tweak our translation engine, we can reduce this human intervention to minimum.
شكرا للقراءة
Sanyam Jain
