Looking at the fixtures of typeorm-i18n the solution is based on having a separate column for each translatable field for each supported language. Though this may yield the simplest database schema design, I would only use this if you have very few (1-2) translatable fields, and only a small couple (2-3) languages to support, and don't foresee this to change in the future.
In most other cases I would look into having a true multi-language database schema. There are some nice StackOverflow answers that explain possible solutions, like Schema for a multilanguage database (also look at solution #5 in the second answer). It happens to be that this answer was linked to from the (at time of writing still open) TypeORM github issue I18n messages.
In the issue @michael-bromley suggests a nice TypeORM solution based off of this (be sure to read the follow-up as he is now using a modified version). Solution evolved and implemented in his own open-source e-commerce product Vendure (see translatable Product entity).
At the end of the issue an N-to-M relationship between Language and Product is also proposed.
To me Michael Bromley's approach seems a good one. But you'll probably have to distill the latest version from his Vendure project.