`extract` Command

[lorenzolewis]

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:

1. Add in t() into my Astro files
2. Run astro-i18n extract to extract/update all keys in the en.json (or default locale) file
3. Upload those English JSON files to a translation service (like Crowdin)
4. Crowdin generates and updates the respective files for other languages
5. Download the non-English JSON files from Crowdin
6. Run astro-i18n sync to then generate the non-English routes based on the downloaded JSON files

I'm excited to see this project and this part of the Astro platform shaping up! <3

[Alexandre-Fernandez]

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 ?

[lorenzolewis]

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.

[Alexandre-Fernandez]

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.

[lorenzolewis]

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!

[Alexandre-Fernandez]

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.

[Alexandre-Fernandez]

added in astro-i18n@1.5.0