activist
activist copied to clipboard
activist-org
Investigating and potentially implementing i18n object
Terms
- [X] I have searched open and closed feature requests
- [X] I agree to follow activist's Code of Conduct
Description
In discussing how i18n is working, @Robert-Kovalcuk suggested that we look into loading the JSON into an object with keys that reflect the structure of the JSON. This would then allow us to use auto completion to enter in the keys, and we'd also receive errors if they were spelled incorrectly. Incorrect spelling of the i18n key routes would be great as for things like aria labels them being assigned incorrectly won't be readily apparent.
One thing to consider is how to make sure that it works when some of the i18n locales won't have all of the keys given that their translations may be incomplete.
Contribution
Happy to discuss this and help implement!
Today I'll figure out if the approach I suggested is even possible just by reading the .json file and making an object, where object key is .json key and value is key but of string type, from it we get the autocomplete that we'd want. It doesn't sound like something that should work easily, but I'll know better at the end of the day.
I solved the issue, by adding a script to a post-install hook, which im not entirely sure is the best approach, but the script reads the en-US.json file and creates an object from it and stores it in utils folder as localeMessages.ts. By invoking the script in post-install hook, we make sure everyone will have the object present when developing, since everyone runs yarn install. I'm not sure about it being the best practice for this however.
https://vue-i18n.intlify.dev/guide/integrations/nuxt3.html#optimize-with-intlify-unplugin-vue-i18n - I also found something like this after creating the solution for the issue.
Checking in on this one as well, @Robert-Kovalcuk 😊 I was doing a lot of i18n work the other day and realized that we are checking if the string is defined more than once and if it's not used at all, but we're not checking if a string we're passing would be incorrectly defined. This would almost certainly fix this as we'd be getting errors for incorrect references :)
As stated in #544, happy to do a call sometime if you'd have time!