1

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

  1. 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

Improve this question
2
  • With #1, what are you going to do if you have two books with the same English title but different Chinese titles? Commented Jun 12, 2020 at 18:53
  • @PhilipKendall In my case, the titles are guaranteed to be unique. Will that work with #1? Commented Jun 12, 2020 at 18:54

1 Answer 1

Reset to default
2

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.
Improve this answer
3
  • Thanks. For option 1, if I were to store the English title in resource file as well, what would I use as the "key" to pull specific books? Will the resource store the primary key of the book entities as well then? Thanks Commented Jun 17, 2020 at 15:50
  • If the ISBN is the key then that would not apply for me. I was using Books as a sample of what I need to do localization on. The data I will be working with is unique and does not have any unique key like ISBN. In that scenario, would you still say to store English in the resource file? Thanks again Commented Jun 17, 2020 at 20:05
  • @overloading Because I don't know your domain, that's why I can't suggest you good lookup key. If your lookup key is a surrogate key then yes the English localization should be stored in the resource files as well. If your lookup key is a composite key ({title}_{publication_year}_{main_author}) then you should still store the title as a resource because the lookup key can have constraints, like do not allow the following characters: #, !, - , `, etc.. Do you get my point? Commented Jun 18, 2020 at 6:24

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.