Storing translation as JSON files (without TS sugar)

[cheburan]

Hi @mechkg , @lukashroch!

I have an idea regarding the vue-i18n translation files. I am about to add two new languages to the code base, which will bring an overall number of default languages to 6. It would be painful enough to update all of the languages if something was added or changed in the prompts survey or admin interface. So, I thought about two options:

1. Store translation files in separate JSON files as objects without any TS sugar. So instead of having common.ts like this:

import type { LocaleMessageObject } from 'vue-i18n';

const common: LocaleMessageObject = {
  _: 'Intake24 Admin Tool',
  title: 'Common',
  login: {
......
}

Have something along these lines:

import type { LocaleMessageObject } from 'vue-i18n';
import localeTraslationObject from './common.json'
....

const common: LocaleMessageObject = localeTraslationObject;
....

Ideally, it will allow running a CLI script that checks English JSON files and syncs all the other languages with them (either automatically or manually).

2. Another thought - de-complete all translations to the separate repo of JSONs. I suggest leaving English as default, but all other languages are outside and can be included as needed.

Any thoughts?

[lukashroch]

Maintaining lang files will become a chore once the numbers grow, that's for sure. Especially when there are lots of moving parts.

Having translations as JSON files should be fine though. I think it's already supported and new vue-i18n for Vue3 might actually have better TS support for JSON (https://vue-i18n.intlify.dev/guide/advanced/typescript.html) also vue-i18n bundler https://github.com/intlify/bundle-tools/tree/main/packages/unplugin-vue-i18n

I wouldn't duplicate number of files, like having both common.ts and common.json, you can just have latter and load then from top level. Basically, convert .ts to .json.

So the only thing I would watch out is not to introduce some unnecassary incompatibility with vue3.

I think we might just need some overall top-level type cast for database model as there is not much other type-safety to it other than that.

Re 2, I'm not sure what separate repo would solve in this case? But generally speaking ... please no submodules/subrepositories, they are so much pain :-(

Btw I wonder if we should duplicate admin part, as it looks to me it is not yet translated anywhere with those newly added languages? So at the moment it just creates work for us to update en duplicates. And it should just fall back to en anyway, or we can load them with default en version until someone brings the translations to it.