.NET Core localization Web API

Question

I have a Web API application that needs to support localization for multiple languages, and I want to know which approach would be most suited.

For simplicity, if I have a collection of books in the database, and the titles need to be translated into different languages and return to the user, is any of the following good for the need?

1. Store the default language (english) title in the database. Store the translated titles in resource files. Then, when the user requests the Web API for (chinese) title, I will perform the following steps:
   1. Pull the default english book title by Id
   2. Use the english book title as key, pull the translated value from chinese.resx resource file
   3. Return the translated value

OR

2. Store both default language and translated titles in the database but separate tables. Pull the translated table as a relationship and return the titles to user.

I am leaning toward #1 as I have done #2 before and it was not that easy to maintain translated text for me in database. But I am not sure if there is any downside in implementing #1. Or is there any other approach to this? Thanks

Answer 1

Option 1

As Philip Kendall has pointed out there can be scenarios where the natural / intuitive resource lookup keys can cause ambiguity. That's why an artificially created identifier can be a better choice. For example in your case the (13 digits long) ISBN seems to be a more suitable lookup key.

The English title could also come from a resource file, so you don't have to persist them in two separate stores (db+file). So, something like this

• BookTitles.resx (Contains titles in English)
  • BookTitles.fr.resx (Contains titles in French)
  • BookTitles.de-De.resx (Contains titles in German)
  • etc.

If the specific can't be loaded then you can fallback to the original.

Pros

• This lookup and fallback functionalities are built-in features of .NET
• You can send out resx files quit easily to Translation Agencies

Cons

• Localization files can go insanely large
• Depending on the usage of resx files (for instance if they are complied into the assembly) it could require a full redeploy to fix a simple typo

Option 2

You can have a table called TitleTranslations, where the key is the LanguageCode and ISBN. Your lookups can be done quite easily in this case.

Pros

• You can add new translations, fix existing ones without redeploy
• Creating reports from translation coverage is quit an easy task

Cons

• It can be a tedious job to extract data for Translation Agencies and then bulk import them
• It is not very scalable approach. Today you have to store only titles, tomorrow can bring you 13 more properties of your book model. Building really flexible db schema to support this can be really challenging.