feat(cli): made i18n command more robust

[partik03]

Should close #185

[partik03]

@maxprilutskiy kindly review this pull request

[maxprilutskiy]

Hi @partik03 – thanks for the PR, it's almost perfect!

Some feedback:

1. pnpm new (from the root) -> add a brief summary of your change, don't leave it empty
2. Please revert the changes made to the lockfile
3. Finally – let's simplify your PR: I like the concept behind --strict in general, but let's be even more ambitious, and throw always, treating it like --strict is always there.

Wrap the following with try/catch to prevent a single localization failure from breaking the entire localization run:

const processedTargetData = await localizationEngine.process({
              sourceLocale: i18nConfig!.locale.source,
              sourceData,
              processableData,
              targetLocale,
              targetData,
            }, (progress) => {
              bucketOra.text = `[${i18nConfig!.locale.source} -> ${targetLocale}] (${progress}%) AI localization in progress...`;
            });

... and just throw everywhere else (if the config can't be loaded, etc).

Let me know if the above doesn't make sense, I'll provide more context!

[partik03]

@maxprilutskiy for what I have understood you want that I should consider throwing error every time and stop the execution on the first error (if I consider --strict is always there), then I think we'll just revert back to the existing behaviour only with better error handling

Am I correct?

[maxprilutskiy]

@partik03 ah I see what you mean!

1. Some errors, like "we couldn't read your config" kind of errors, must fail the entire command execution flow and stop the execution of the command, because this type of things is a critical error that 100% would fail the following steps.
2. Other errors though, like "we couldn't localize en -> hi" kind of situation, must not break the entire command (unless --strict is enabled), because we're still capable of continuing and processing other locale pairs.

While this is not VERY obvious, this improves the developer experience significantly, given the feedback we receive. :)

Let me know if the above makes sense!

[partik03]

@maxprilutskiy got it!

[partik03]

@maxprilutskiy I have completed the desired changes

[maxprilutskiy]

great job

[maxprilutskiy]

this empty changesets file can be now safely removed, since you've added a meaningful changeset message

[maxprilutskiy]

Loving the concept!