What to be considered when develop multi-national web based application
Published: 2020-05-31 23:01:40

These several months were really interesting to me. Starting in November, last year, I was assigned to develop an application, a plugin actually. This plugin would be part of a very big and famous application served more than 100 million users all around the world. Sorry, I can't mention the name. It's an honor for me to be part of this project.

So, basically the project is to write a plugin for an Android/iOS application. They have a plugin framework that we, developer, need to follow. The plugin would be written in web based language for easier deployment in Android or iOS.

And this is the first time I in my life to write a really multi-national web application. Today, I would like to share what to be considered when develop such application.

## Limitations
As a former Android developer, when project manager from head quarter ask me these questions: 
1. Can you get user country? Because we cannot sell this TV in China. And we will put *Purchase Button* to these page in United States, but not in South Korea.
2. Can you save user's choice, for example: don't show this page after user give check mark on the "Don't show this again." text?
3. Can we support tablets as well as phone devices?
4. Can we implement dark mode?

I answered, "Yes, I believe it can be done. Technically." 
I said this in my heart, "Of course, I'm senior and professional programmer. These requirements are pieces-of-cake".

Well, I was totally wrong. 
1. The usage of [Geo Location API](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API) is prohibited.
2. The usage of [LocalStorage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Local_storage) is prohibited.
3. Android *WebView* is currently doesn't support [Media Query's prefer-color-scheme](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme).
4. Well, there is still hope. At least I can distinguish tablet or phone with [Media Query](https://css-tricks.com/snippets/css/media-queries-for-standard-devices/). However, lately I found that the method still has flaws. There are new phones detected as Tablet. Also I found some issue on super high resolution tablet like Samsung Galaxy Tab S6, which is detected as [SM device](https://material-ui.com/customization/breakpoints/).

So, what I want to say to you is to always prepare for plan B. Our original plan might not work. But we believe that our host application was a mature application. They prepared almost all that we need.

Yes, they made a quite thorough API. 

## List the angels
There would always be some problems. Of course. That's why we are being paid, right? To solve the problems.

We might not be able to solve all of our problems ourselves. We're human. Even if we're programmers, sometime we need to ask another smart guy out there. Unfortunately, not all smart guy are willing to share their knowledge. So, if someone willing to help you, remember to save their name, email or phone number and what knowledge we can have from them. Not all information are written on the documentation. Believe me.

## Framework save our time
I used [Ionic Framework](https://ionicframework.com/). AFAIK, there is no one in our company used this framework to write the plugin. I thought it is because this is not the normal use case for Ionic Framework. But their collection of components is a great help.

It's not that we could use their component as is. Actually, we need to make customization everywhere to show our brand. But the basic behavior of the components are common. Button will have ripple. Check box and radio button will have check/unchecked state. Etc.

This framework save my ass in the first 2 weeks of development. Within 2 weeks, we can deliver our PoC, and the bosses were quite happy with our development speed.

## i18next
Serving hundreds of millions users means we need to handle more than ten languages. That means, when you make a button with text for example: *Save*, you must prepare more than ten of the translation of *Save*. Not to mention some languages that you cannot even type it with your finger.

Unlike Android, the world of JavaScript exists before the language platform even exists. So, yes, there is no unified best practice to implement the translation. So, you need to define it yourself.  

[i18next](https://www.i18next.com/), an internationalization-framework would be a great help. My intention is not to teach how to use this framework. I would just mention that such framework exists. So, you don't need to *re-invent the wheel*.

I use this framework in ReactJS as [hook](https://react.i18next.com/latest/usetranslation-hook).

## Design with translation in mind
Beware that human expression are differ one another. I will try to explain this with an example. 

For example, I create an Android application. The first page of this application show list of electronic devices grouped by the room it belongs to. So then I will have group named *Living room*, *Kitchen*, *Family room*, etc. *Living room* will have television, coach lamp, air conditioner, air purifier, etc.

The designer decide to differentiate room with the electronic devices in it just with a white underline below the room name. OK, it's easy, right.

Then problem happened. Nice quite long name **Living room** translated to Korean only as two tiny characters **거실**. The design were broken. Gave these two characters a white underline, make it just like no different with the other items in the list.

In the second page, the app list down automation. Each item in the list consists of 3 part. An icon of the device in the left, a button with *Run* text in the right, and automation name in the center. This design seems perfect in for English. Proportional. The **Run** button have nice big padding. However, some good guy from Mexico report an issue in this page. So, Mexican as well as other Spanish speaking countries will translate **Run** as **Ejecutar**. Then, the button became too big. Taking space.

So, if your role is a front end designer, please keep translation in mind.

## There are people right from Right to Left
There are at least two language uses RTL (right-to-left) direction. Arabic and Hebrew. If users from the countries using these two languages are important to your app, then consider to write your app to support RTL. This is not only affect the text. In my case this also affect the UX more than we expected. For RTL, even the drawer menu came from right side, the *Save* button reside in the left side and *Cancel* button will reside on the right side.

So, please prepare the app to support RTL if the user with RTL reading direction would be important to your app.

The good part, in HTML, we have `dir='rtl'` that can be applied on HTML tags.

## More will come
I have some more items to be consider when writing an app to serve millions of people from around the globe. But I need more time to write it down.