DEV Community

Luciano Fiandesio
Luciano Fiandesio

Posted on

Internazionalization best practices

Hello,

I'm building an app based on Vue which consumes data from a Spring Boot based API. I have internazionalized the front-end with Vue, without issues, using a resource file.
Some of the API calls should return some localized content, based on the user-selected locale.
I can easily make the API to return different transalations, but that means that I have to maintain two sets of translated content: one for the front-end and one for the back-end.

Is there a better approach to this (keep all the translations in one place)? Also, what would be the best way to do this? I'm thinking of passing the user locale to each API call, setting the language in the HEADER (Accept-Language).

Thanks!
Luciano

Top comments (4)

Collapse
 
dansilcox profile image
Dan Silcox

One way would be to return a translation key either instead of the default message or as well as - as a fallback and to prevent you having to change much. That way you can manage the actual translations in one place (ie the front end translation management solution whatever that may be) and keep the backend changes relatively simple/small after the initial effort of adding the keys. Plus most translation/I18N solutions allow you to inject variables into the actual translation text so you can do things with calculated/DB retrieved values without having to have 2 lots of translations to manage :) All the best with it!

Collapse
 
lucianofiandesio profile image
Luciano Fiandesio

Yes, I like this approach. I just need to keep the front-end resource file in sync with the transalation keys living on the db.

Ultimately, I could keep everything in the db, and generate the resource files at build time, so that they are constantly updated.

Thanks!

Collapse
 
dansilcox profile image
Dan Silcox

Also means you don’t need to even worry about the language headers :)

Collapse
 
rolfstreefkerk profile image
Rolf Streefkerk

The way I solved this for our app is to use ISO standard 3 character language codes (ENG, THA, etc) and feed them into the API when retrieving content. For GET requests it would be part of the query parameter set, no need for specific headers.

On the front end we have a single admin area where you can manage all the language variants and this gets stored on the DB.

This includes translations for non dynamic content such as menu header text etc. which you can easily cache once set.

Advantage is that your app doesn't really care about language, it's just displaying text