This post will be the story of an interesting Open edx instance. We all know the Open edX platform is a big, complex, capable tool. Every Open edX instance can be configured in a different way according to its needs and objectives. Consequently, it will bring another story to the table.

There are two actors in this story. The first one is Turkey Tourism Promotion and Development Agency (TGA). TGA is dedicated to promoting Türkiye as a brand and a popular destination in domestic and international tourism. The other player is Artistanbul, a technology company offering open-source software solutions. Artistanbul has provided installation and hosting, platform customization, and course development services for the Open edX platform for the past 6 years. Artistanbul provides Open edX services to NGO’s, universities, and companies. Thus, they have a vast amount of experience related to Open edX configurations. In this story, Artistanbul is the Open edX Marketplace Provider who installs, customizes and maintains the Open edX platform for TGA.

This story is about languages, many of them. The Open edX instance that we will talk about in this article currently supports 13 different languages (Turkish, English, German, Romanian, French, Dutch, Spanish, Hebrew, Russian, Arabic, Chinese, Polish, Ukrainian) and this number is increasing every day. Supporting many languages requires some experience and we believe it can be helpful for Open edX maintainers to hear about the know-hows in this manner.

Artistanbul’s story with languages in the All in Türkiye project ( ) started on the Open edX Koa version. At that time there were no microfrontend structures and Artistanbul was able to add languages with only a flag on the admin page. However, they updated to Olive recently and had to rediscover this language maintenance process from scratch. The reason for that is, the previous method (also the method suggested in Tutor documentation) didn’t work after MFEs were integrated.

What does the pipeline look like? First, the decision of the language comes from the operational side of TGA. Then they create modules for this language to be added. Meanwhile, Artistanbul adds languages to their test instance. Here it is nice to note that there are two different installations as test and production. All changes are made first in the test instance. If controls pass, then they make them in production too. After they add the language in the test instance, Artistanbul may catch some missing translations. Then they ask for their correct translations and TGA communicates with translators. Following this step, Artistanbul updates both .PO files and hardcoded translations if needed. After everything is done, they make these changes in production and import the module. And there it goes, a new language has been added.

Why is it tricky to support multiple languages? This question has both technical and operational answers. Artistanbul uses Olive in the All in Turkey project. The method that is suggested in the Tutor documentation didn’t work for microfrontend applications so they needed to edit the source code of the MFE applications instead. This caused their own package management problems. Another difficulty is that Artistanbul has to make sure .PO files are formatted correctly and work properly after every edit. Lastly, languages have differences that may cause some extra work. For example, some languages are RTL and some are LTR, thus the certificate design differs between them.

On the other hand, operational difficulties also exist. Sometimes, copying and pasting a text you can’t read may cause mistakes that are hard to recognize. Also, copy and paste sometimes format the text from LTR to RTL or RTL to LTR and you won’t even know, as a person who can not read that language.

If you are interested in supporting multiple languages on the Open edX platform and want to learn more, please don’t hesitate to contact Artistanbul. You can also see the recorded meetup presentation about this topic on the Open edX website ( ) or on YouTube ( ).