Building a large scale application is hard for teams, harder for single developers with low budget and much more harder for anyone if the application is multilingual.

We’ve experienced that first hand during our ongoing project, then T9N Manager was born. As it became a standalone module within our application, we wanted to separate and share into the world of developers.

We are working mostly on Vue.js at the front and PHP at the back-end. So the translation files we produce are should be usable with vue-i18n. It basically requires file formats like this:

// translations-all.js export const messages = {

en: {

message: {

hello: "hello world!"

}

},

tr: {

message: {

hello: "merhaba dünya!"

}

}

}

With a proper configuration, you can separate translations into distinct files:

// en-US.js export const messages = {

message: {

hello: "hello world!"

}

} // tr-TR.js export const messages = {

message: {

hello: "merhaba dünya!"

}

}

And get rid of named exports:

// en-US.js export default {

hello: "hello world!"

} // tr-TR.js export default {

hello: "merhaba dünya!"

}

As the amount of your keys (eg. hello in above examples) increases, it’ll become harder and harder to keep those files synchronized. Most of the time vue-i18n or some other plugin of your framework will tell you when a particular key missing on a file, but it’ll not ease the pain of walking two steps forward and one back each time you forget to add a key to your second or third (even fourth?) class translations file.

I don’t even want to mention what happens when you decide a key is not very definitive for the context it has and needs to be changed. You know what I mean right? I bet yes, you do developer. Now you go back all of your translations files and find that ugly key and replace with new one.