How about strings that are not part of the code (for example, they come dynamically from database)?

Our current focus has been on handling content found in code, but we have plans to expand our capabilities to handle dynamic content in real-time. To lay the groundwork, we are initially working on the basics of Native implementation, specifically content within the code. This approach allows us to address more complex challenges associated with dynamic content, such as accurately detecting placeholders and variables. By doing so, we aim to avoid sending irrelevant content for localization, which could unnecessarily increase word count and complicate management.

We are pleased to share that we have identified workarounds for two specific scenarios:

  1. Handling strings from databases

  2. Translating variable strings within strings, which often arise when reusing email templates.

  3. For handling strings from databases, a possible solution involves utilizing code similar to the following example:

However, when using a variable as an argument for the t() function, there can be a challenge in directly extracting the string using the CLI tool. Nevertheless, during runtime, the t() function is unaware of the source of its argument, whether it came from a variable or a string literal. It checks its cache and utilizes a translation if available. This means that although direct extraction from a database is not possible with TxNative, translations can still be performed if the source-translation pair is present in the cache. As a solution, customers can create a script to iterate through the database and push the source strings via the API. Subsequently, the application can utilize the t() function to display the translations.

  1. Addressing the translation of variable strings within strings, particularly in emails, poses another challenge. While the majority of email content can be successfully translated using Transifex Native, variable strings remain untranslated. A suggested solution is to perform the translation on the Python side, outside the template. The following pseudocode example illustrates this approach:

This solution ensures the translation of the variable, although it may require rewriting existing emails. Instead of directly retrieving the emails from the database, each variable needs to be individually transformed (e.g., session_title = t(session.title)), and the emails must be updated to use the transformed variable (session_title). Despite the potential need for rewriting, this approach represents a significant step towards achieving comprehensive translations for emails containing variable strings.