Related to #6 (better idea).
The problem
Some users keep localization files in YAML, or even JavaScript files.
Technically there are no limitations to handle that. But currently we can only process the .json files.
Example: https://github.com/HugoBlox/kit/blob/f107371dc2b625fe876f7b8b7f50123d1b8a17c9/modules/blox/i18n/cs.yaml
The solution
We could introduce the codec concept in config.
User would describe a codec object that can pre-process files and convert it into JS object (record), and convert record back into files.
The config API draft:
export defineConfig({
include: '*.yaml',
codec: {
decode(context: { file: string; getContent: () => Promise<string>; language: string }): Record<string, unknown> {
return yamlParse(await getContent());
},
encode(content: Record<string, unknown>, context: { file: string; language: string; }) {
return yamlSerialize(content);
},
}
});
This way would allow users to translate any structured files, including .js/.ts files (via use the language specific AST utils).
This feature require to implement the include option to let user scan any files that match the pattern, not only .json files.
Related to #6 (better idea).
The problem
Some users keep localization files in YAML, or even JavaScript files.
Technically there are no limitations to handle that. But currently we can only process the .json files.
Example: https://github.com/HugoBlox/kit/blob/f107371dc2b625fe876f7b8b7f50123d1b8a17c9/modules/blox/i18n/cs.yaml
The solution
We could introduce the codec concept in config.
User would describe a codec object that can pre-process files and convert it into JS object (record), and convert record back into files.
The config API draft:
This way would allow users to translate any structured files, including .js/.ts files (via use the language specific AST utils).
This feature require to implement the
includeoption to let user scan any files that match the pattern, not only.jsonfiles.