Skip to content

Website Localization Strategy Discussion

Jump to bottom
OlenaOsadchaBA edited this page Sep 18, 2025 · 11 revisions

Date: 28 Aug 2025 Participants: Experts, Development Team

Topic

Implementation options for website localization (content translation).

Discussion Points

  1. Content Translation via Admin Panel

    • Two strategies for enabling English localization were discussed:

      Strategy 1 – Translation Service Integration

      • The system will provide an “English mode.”
      • Ukrainian content will be translated into English through an AI-based API.
      • The administrator will be able to review, edit, and publish the translated content.
      • Provides a controlled workflow where translations can be refined before publication.
      • Rominos7’s preferred option.

      Strategy 2 – On-the-Fly Translation Switch

      • Each admin modal or page will include a switch to activate English mode.
      • Activating the switch triggers automatic translation of the displayed fields.
      • The administrator can edit the translated fields directly and save them.
      • Offers real-time preview but may complicate editing workflows.

  2. Data Storage Considerations

    • Discussion on saving translated content in a NoSQL database (e.g., MongoDB) @maxvonlancaster TBD.
    • This approach would allow flexible handling of multilingual content files and improve scalability.

Key Takeaways

  • The expert recommends proceeding with Strategy 1 (translation service integration with admin review).
  • MongoDB or another NoSQL database may be used to store translated content for better scalability and content management.

Architecture Description of Localization

Date: 18 Sept 2025 Participants: Experts, Development Team, BA, designers

This document describes overall approaches and implementation essentials.

It tells about:

  • Generic description of the architecture idea
  • Architecture logic – description of the components
  • Justification of the selected approaches

Glossary

  • Localization – feature that allows to view the content in different languages.
  • Static localization – localization of the static content, that doesn’t change over time and is embedded into the page.
  • Dynamic localization – localization of the dynamic content, that can be edited by the admin, hence can be changed over time.

Architecture

Architecture overview

Localization can be categorized as Static and Dynamic.

  • Static localization

Managed automatically by the application and dynamic can be adjusted by the admin. Overall architecture is built so that it can support the possibility of adding more localization languages later. It also allows partial localization, where only a part of the content is translated to some language.

Static localization is quite straightforward to implement. It involves switching between different content provided by JSON files. It is implemented with the use of the i18n-react library. All necessary text is predefined and stored on the frontend. So, changing the content in any way requires developer attention. This shouldn’t be a problem though, as this kind of localization isn’t supposed to be changed frequently. The majority of the work on this type of localization will take place on the visitor page.

  • Dynamic localization

Dynamic localization involves the ability to change the translations by admin, so the displayed page content is changed too. This feature consists of 2 parts: creating and updating the text context and generating the translation via special service. Translated content - backend implementation The core idea is to store translated data in a different table. This way an entity can have its own original data in its table (for example Team member) and its localizations in a second table (Team member localizations), where only text data is stored, along with the language of the provided translation. It gives a concise way of storing translations, without affecting the core data allowing the existence of multiple languages for the same entity. Note that it stores only the localizations, the original data is still in the main table. The example with the Team member entity along with the database schema is shown below.

image

Following the example any entity can bring up the same idea – main data is in the original table, translations are in the other. Notice that there is a table where localization languages are stored, because each translation has its own languages. While there are only 3 fields there, it is possible that there may be more (for example, language name, or other formats). It is also important to note that we are going to use ISO 639-1, which implies that language codes will be stored as two symbols, for example “EN”, “ES”, “DE”. As for BLL and WebApi layers, they will be implemented with use of basic CRUD operations, so that providing a localization for some entity will require sending a corresponding API call to an endpoint in a dedicated localization controller for that entity.

image

Translated content - frontend implementation

From a visitor perspective this won’t look like much, all the user would need to do is just switch the language, and the application would change the static content and make an API call, fetching all the dynamic content in the required language.

The admin side is a little bit more complicated. It requires straightforward functionality for managing the localization, without introducing too much complexity. Thus the localization management system will be integrated into the existing panels, so that the core interactions will remain the same.

The admin side is designed around several core principles:

  • Simplicity – the admin should be able to easily and effectively manage localization, without additional assistance or special guidance. This is also a reason why a separate localization service is not taking place.

  • Separation of concerns – this means that there are 2 separate flows, in the first one admin creates and manages the entity itself, in the second admin adds translations.

  • Flexibility – admin should have enough control when providing translations and decide which translations to add. This also means that if an admin forgets to add a translation for a specific entity, it is the admin's fault. However, this requires an effective way to inform the admin about the current situation to mitigate this downside.

  • Scalability – this means that if we were to add a new localization language it wouldn’t break the existing data state and can be easily performed. Also adding new entities shouldn’t require any major changes in the existing localization system and should not break anything either.

  • Localization is dependent on the entity, but not vice versa – here it means that entity core management shouldn’t be affected by localization, as it would break concept 2 and 4. And if it wasn’t like that, then any change in localization would also affect the entity itself, and keeping the correct data would get harder each time we add a new language to the system. Also publication and drafting of the entity would automatically affect the localization, as localization doesn’t have its own status.

Those ideas are related not only to the UI and UX parts, but also to the overall logic, and violating any of these concepts may introduce extra complexity both for the localization system and existing logic itself. So they are important to keep in mind.

Translation generator service This will be implemented later.

Clone this wiki locally