Ajackus Partnered with VTS to address the localization needs of their core product offering. VTS was founded by real estate professionals who have experienced the challenges facing today’s landlords and brokers first-hand. Armed with these insights, VTS delivers an easy-to-use, intuitive platform that empowers commercial real estate professionals to work smarter not harder.
VTS’s core product offering required support for multiple languages to support their expansion in the North American market and other territories. Initial product development was done without keeping in mind Localization. The goal was to cover key areas of the application first to make the product offerings relevant for new incoming customers.
The focus was on addressing two areas,
Process gaps were revolving around missing infrastructure.VTS was lacking two areas of robust process: translation process and development process, though the two are closely coupled.
The development process was hindered because of the lack of pace & automated translation tools. Translators used to work on a weekly basis, meaning the turnaround time for translations was a minimum of 4-5 days. A truly agile localization process requires a turnaround time of less than a day. So, we made the necessary changes to enable the same.
Translators were directed to do translations on a daily basis. For all new localization work, we came up with a new branching process that was aligned with the existing process of other teams and made most of the new frequency of translations.
Technical gaps involved product areas that were not localized. The preference was given to reporting and emails. Reports were in two formats: Excel and PDF.
Excel posed challenges in making most of the native localization features & formulas. It required us to constantly tinker with inbuilt settings and check how the desired result can be achieved. On the other hand, PDF posed challenges in ensuring different length strings in different languages do not end up disrupting non-flexible PDF layouts. Pseudo-localization came in handy at each step.
Pseudo-localization is designed to catch the problems mentioned above. It is the process of verifying that your product is ready for localization. It helps you see how a product’s UI will look after translation, without actually creating a real translation. Instead of translating the text of the product into a different language, the textual elements of a product are replaced with an altered version of the original language.
For example, with pseudo-localization, the phrase “Account Settings” becomes [!!! Àççôûñţ Šéţţîñĝš !!!]. This translation remains readable to English speaking team members and allows them to see translation-related issues.
Next, we took up on emails. With emails, development was not a challenge, however, testing was. Mainly with the event-driven emails that are triggered by the system at a regular interval eg weekly digest email. We created a command utility that allowed QA members to trigger any email on any account with the desired language. We restricted this utility to lower environments only. As a follow-up, we put in place a UI that could render any email and make email testing further easier.
Email in English
Email translated in French
We were able to achieve our desired results well in advance – 100% of reports and emails at VTS are now being translated into a user’s preferred settings!
We are available in 5 cities and also on the world wide web making us reachable to anyone on the planet with an internet connection.