jbukuts / markdown-translate Goto Github PK

Currently frontmatter data is stripped from the markdown into an JSON object before the document is uploaded for translation. It is then added back in at the end of the process

This issue revolves around adding an option to specify values within the frontmatter that need to be translated and then using the token API to do so.

Ideally this translation should occur after a translated document is successfully retrieved. If a failure occurs at this step then the original text can act as a fallback.

Current batch processing just takes an array of files and maps it to an array of promises and awaits all their resolutions via Promise.all().

This is fine in small batches but when throwing a large amount of promises it may just cause a stall. With this in mind it's probably best to rework the logic to use workers instead with some form of queuing.

For some reason, the translation services are not ignoring translation in code blocks.

This leads to a need for manual intervention after the translated file is created.

This issue is to track a potential fix by wrapping code blocks in items not translated by the service and then unwrapping them after the fact.

Want to make the addition of more APIs modular and easy to integrate. I tried to enforce this using JSDoc comments for typing which works to a degree. But the use of interfaces doesn't seem to work properly.

Ideally a single interface should be defined which is then implemented for the various APIs making their use and definition easy to follow.

This issue tracks either continuing with JSDoc and creating types from that. Or instead just moving to TS as a whole for the source code and transpiling the releases to JS.

Currently, MDX custom components are removed during the initial transformation from Markdown to HTML. All that remains is a encapsulating div item in the resulting HTML string. This issue resolves around finding a fix to ensure that MDX JSX syntax remains intact.

Given batch translation/localization of files is an everyday use case it seems like a good idea to support it eventually.

Interesting thought about implementing this using Node's worker threads to achieve this in parallel.

Ideally, this could be published as an NPM package so the script could be used in pipelines with Markdown content.

Some steps to get to this stage:

• Add testing via Jest
• Ensure semver bump when creating PRs
• Add env variable check as another way to pass values rather than CLI
• Ensure minimum node version when installing the package
• Add workflow for creating/updating the package

Logging is currently very simple and needs to be more useful.

Proposed improvements

• using chalk to colorize
• logs should indicate what file is being acted upon
• clean-up unneeded logs

It can be tedious to always require the API key as well as other variables in the command. This issue tracks adding support to check if they exist as environment variables as well.