Closed lorenzolewis closed 1 year ago
I don't understand why would you need to extract your translations if you already have .json
file. And if you don't have any, there's nothing to extract. Unless you are adding your translations in the config file ?
I don't understand why would you need to extract your translations if you already have
.json
file. And if you don't have any, there's nothing to extract. Unless you are adding your translations in the config file ?
This is assuming that you're first adding your translations somewhere else (such as a service or directly in a .json
file. The use case I'm looking at is if instead your Astro files were the first place strings show up (or their respective keys). In that case it can be useful to parse out those strings contained within t()
and then write those out to the .json
file.
So in this case the strings/keys you're adding to t()
don't already exist in a separate .json
file, but you'd like to effectively parse them out to a new .json
file (or in the case you already have one, just add new strings/keys).
Then you can upload the version with the keys/strings to a translation service, have them translated, and then on the next build you can then reference the newly translated strings.
Hopefully that makes sense. This whole thing is looking a little further upstream in the process before you even have the .json
file ready and need to get that in an automated fashion so that you can then begin translation work.
For t
to run, a request need to be made (and only the functions used for that request will run). For this reason, as far as I know, it won't be possible to get the keys programatically.
The solution would be to parse project files looking for the t
functions and get the string from there. However this will fail to get the value of string variables.
This is an interesting but tricky feature to implement correctly, I'll think about it, and may implement it when I have more time. If you need this faster you may submit a PR.
Sounds good!
For future reference astro-i18next
has their on their roadmap https://github.com/yassinedoghri/astro-i18next/issues/19 and mention using a combination of https://github.com/i18next/i18next-parser and https://github.com/withastro/compiler. But they're also using i18next which you aren't for this project from what I can tell looking briefly.
Thanks again for the exciting project!
But they're also using i18next which you aren't for this project from what I can tell looking briefly.
Indeed this was coded from scratch to be tailored to Astro, independent from i18next
, free to add any custom features and much more lightweight.
added in astro-i18n@1.5.0
One of the functionalities that are missing for me are extracting all of the values from the
t
functions out to the.json
file.If you don't already have a JSON file with your translations setup in a structured format this can be a sort of "quickstart" way to generate that file.
The workflow I could see is like this:
t()
into my Astro filesastro-i18n extract
to extract/update all keys in theen.json
(or default locale) fileastro-i18n sync
to then generate the non-English routes based on the downloaded JSON filesI'm excited to see this project and this part of the Astro platform shaping up! <3