Translating Strings from DB Fields

We are working on a code change in edx-platform and would ideally like to store certain data points in a MySQL DB table. The code would then loop through the data (based on specific filters) and display specific field values (i.e. name) to the user.

We were able to find the documentation on how to format strings so that they will be properly shown in the appropriate language, but did not see documentation for this use case. Is there a best practice that is being used for displaying strings stored in a db table in the appropriate language? Are there other examples of this in the Open edX repos and if so can you point us to the correct repos to review?

As far as I know, Open edX translation and localization efforts have usually focused on translating the UI elements, not the content. For example, there is no support for multi-lingual courses. The only exception I can think of is some video components support subtitles in different languages - but those aren’t stored in the database.

From your description, I’m a little unclear on where the DB values are coming from. If it’s user-generated content and you want user-generated translations, then I suspect you’ll be breaking new ground here. (Perhaps someone built a feature in recent years that I’m not aware of though.)

On the other hand if you have a set of mostly-known string values in the database, say coming from a fixture or a migration or some other data source, and you want them to be translated before being displayed to the user but it’s OK for those translations to be “fixed” as part of the codebase itself, then you can simply pass the string values through Django’s gettext (or probably pgettext in this case) after you load them from the database. And you’ll need to use some other mechanism to make translators aware that those strings need to be translated, since they won’t show up in the code as usual. I’m not sure how to do that, but I imagine you could add them to Transifex or list all the strings in a file somewhere, marked with gettext() around them.

I think the third paragraph most closely aligns with the use case we’re trying to solve for. We are trying to find a balance between flexibility and ensuring the data displayed to the user is shown in the appropriate language.

We have written an ADR of the solution we’re planning to use. We welcome feedback on this solution and have marked the ADR as provisional at this time.