Translations in Vue.js (with TS) and Symfony

Dariusz Włodarczyk
3 min readApr 25, 2021

i18n replacement — small Symfony based implementation

Whenever You try to search or ask for support of translation mechanism for Vue.js pretty much like everyone / every article is going to point on i18n. I gave it a small chance since “Hey it’s so popular, it must be the thing”, however I have to say that i18n removal process goes pretty smooth.

What i dislike about i18n is the fact that there is documentation for configuring the plugin. “I mean, there is a documentation so it’s good right?” — well yes and no. The thing is that what I expected was some very minimal configuration or something like that (and actually there is one — I found it later on) but I ended up in some more advanced examples which made me shrug.

“There must be other way for it” — I’ve thought.

Is i18 configuration really that bad?

It’s not, but I found it later on — however I don’t regret that as I already came up with my implementation of trans utilized by Symfony, and this allowed me to learn how Vue.js Plugins work like so it’s still a win + it works.

External packages

  • jsonpath (allows to search for translation strings in json aa.bb.cc )

Implementing trans method (accessible in Symfony / Twig)

The cool thing about one of the latest TS versions (from what I’m aware of — this was not possible earlier), we can import whole json into variable just by doing this:

import Translations rom './translations/frontend/messages.json';

Translation service

Translation plugin

Extending Vue.js with plugin

How it’s used in action

{{ trans('pages.security.login.form.inputs.username.label') }}

Final thoughts

My implementation does not support switching languages but this could be handled very simply with some switch block / conditional loading of translation file.

Pros

  • simple Symfony based trans method implementation,
  • already known syntax of trans ,
  • capable of working directly with json based translation files,
  • clear and easy to use,

Cons

  • without having the json translation files, it’s required to output the json files from the yaml by using for example my command for it:

Before You disagree

  1. While there might be a dislike to use the command for building the json from yaml, upon proper Symfony configuration the json file can be used directly for translations — meaning that the command can be skipped at this point. However I went with the command solution as I simply already used in in other project (as I had no idea that translation files can be simply stored in separate folders to organize them better — and are being processed by Symfony “out-of-box”).
  2. Also the second dislike might be that “the output file contains to many of backend translations which are not needed on front” (in that case, well nothing stand against to store the backend/frontend strings in separated files).

--

--

Dariusz Włodarczyk

Hobby frontend / backend developer — author of Personal Management System. https://git.io/JePh1. You can find me also here: https://ko-fi.com/volmarg.