The Data Mesh - should you adapt?

Image
In actuality, not every firm may be a good fit for the implementation of a Data Mesh.  Larger enterprises that experience uncertainty and change in their operations and environment are the primary target audience for Data Mesh.  A Data Mesh is definitely an unnecessary expense if your organization's data requirements are modest and remain constant over time. What is a "Data Mesh"? As it focuses on delivering useful and safe data products, Data Mesh is a strategic approach to modern data management and a strategy to support an organization's journey toward digital transformation. Data Mesh's major goal is to advance beyond the established centralized data management techniques of using data warehouses and data lakes. By giving data producers and data consumers the ability to access and handle data without having to go through the hassle of involving the data lake or data warehouse team, Data Mesh highlights the concept of organizational agility. Data Mesh's dec

Internationalization: The challenges of building multilingual web applications

At Databloom, we value diversity. We are a multicultural company with team members from different parts of the world, where we speak a wide variety of languages, such as English, French, German, Greek, Hindi, Korean, and Spanish. Data science teams are also so diverse! For that reason, in Databloom's Blossom Studio, we plan to introduce internationalization and localization features to make our application multilingual.

In that context, we want to discuss several aspects that we found relevant when trying to implement a multilingual application. In addition, we also want to share some resources that we found helpful when applying some of these concepts into practice.

1. Translation Methods

We have two main options: machine automatic translations, where an external service performs the translation for us (e.g., Google translator API, Amazon translate), and human translations, where we manually provide the translated texts.

Generally speaking, it is helpful to use online translation services when the content of the website or application is going to be updated regularly and with high frequency over time (such as blog websites and newspapers). On the other hand, if the website's content will not change substantially, it is preferable to use custom translations since they give us greater control over the quality and accuracy of the translated content. Regardless of the chosen method, we also need to consider where we'll store the translated texts (front or backend) and how we'll access that information when required.

2. Localization Formats

It refers to the formats used to represent different aspects of the language in the local country. It includes topics such as content layout and the formatting of dates and numbers.

  • Content Layout: Different languages may have different writing modes concerning the directionality of their texts. While in the case of Indo-European languages such as English, the writing mode is typically left-to-right (LTR), languages like Arabic and Hebrew have a right-to-left (RTL) script. On the other hand, other scripts, typically of Asian origin, can also be written in a top-to-bottom direction, as is the case with Chinese and Japanese. In this context, our web application should be able to correctly adjust its content layout when displaying another language with a different writing mode, just like in the example shown in Figure 1.

Figure 1. This website (https://www.un.org/) supports different writing modes (RTL, LTR) [1].


A recommendation we can give regarding this point is to apply CSS styles using relative positions (start, end) instead of using fixed ones (left, right). In this way, if the directionality attribute in the markup file is dynamically modified (e.g., dir = "ltr" to dir = "rtl"), it won't be necessary to alter the respective CSS styles.

  • Date and time formats: Some countries may share the same base language but may have different ways of displaying dates, as is the case of the US and the UK. While in the former, the date format is MM/DD/YYYY, in the case of the latter is DD/MM/YYYY. 


Figure 2. US and UK date format comparison

  • Numbers format: Countries may use distinct approaches to represent their numbers. Not only may they use particular ways to depict each digit (as is the case between Latin languages and Chinese), but they can also employ different characters to separate thousands and decimals numbers. For example, the US uses the comma character (",") as the thousands separator. In contrast, many European and Latin-American countries apply that same character as a decimal separator.
 Figure 3. The US and Chile numbers format comparison


3. User Experience


We must also consider some UX and UI elements in our web application to manage multiple languages appropriately, like the following: 

  • Language Switch: Usually corresponds to a dropdown list or a select element that displays all the languages the web application supports. The user should be able to change the language when clicking on one of the list items.
  • User Navigation: We must decide if each language will have a specific address displayed to the user. For example, for the English version, you can have the following address: https://www.mycoolwebsite.com/en, while for the german version, you may have this one: https://www.mycoolwebsite.com/de. In the case of single-page applications using Vue.js, this feature is made possible by using the extension Vue router. To simulate that browsing experience, you can create different routes for each selected language. 

  • User Preferred Language: A nice-to-have feature is to display the preferred language by the user right from the start. We can use browser properties like Navigator.language to capture that information in our application. This read-only property returns a string in a standard format representing the user's preferred language in that particular browser [2].
  • Fallback Language: We also should have a fallback language to present to the user in case the preferred language is unavailable or if we don't have translations for a specific language. Typically, the fallback language should be the one your customers use the most.
  • Persistence: Another nice-to-have feature is that choices made by the user persist over time, even when refreshing the web application. One way to accomplish this is by storing the user's selected language in the Local Storage using the Window.LocalStorage property [3].

4. Resources

Implementing all these features may seem like a daunting task. Fortunately, there are several internationalization packages that you can use to make things happen, so you don't have to reinvent the wheel. For example, one that we highly recommend for Vue applications is vue-i18n. This plug-in addresses many of the features mentioned above, such as number and date formats, and also considers other attributes we didn't mention here, like noun pluralization. Furthermore, it works well with both Options API and Composition API.

Other resources you can use to get you started:

References:















Popular posts from this blog

Towards a Learning-based Query Optimizer

The Missing Piece in Learning-based Query Optimization

Federated Learning (Part II): The Blossom Framework