yaml file first line language key and recognition of existing already translated lines

[kgorshkov]

For yaml files, the first line is the language code, such as 'en:'

en:
  hello: "Hello world"

The translation to another language such as 'es' creates a new file es.yml where the first line language code is still 'en:'

en:
  hello: "Hola Mundo"

It would be good if i18n-auto-translation would recognize the first line language code and update it as part of the output translated language file.

The issue is that when the first line language code is updated manually, attranslate no longer recognizes that all following sub or indented keys and their translations are existing already-translated lines if attranslate is run again for updates:

Example:

First run:

Invoke 'google-translate' from 'en' to 'es' with 1 inputs... Add 1 new translations Write target 'C:\Users\KG\app\config\locales\es-test.yml'

Manually edit first line language code to es:

es:
  hello: "Hola Mundo"

Expected on second run with edited existing file es-test.yml:

Target is up-to-date: '.\config\locales\es-test.yml'

Actual:

Invoke 'google-translate' from 'en' to 'es' with 1 inputs... Add 1 new translations Delete 1 stale translations Write target 'C:\Users\KG\app\config\locales\es-test.yml'

Please advise how I can handle yaml file updates, thanks.

[fkirc]

Thank you for the detailed report, I think the problem with your first yaml-line could be solved with a key-replace feature. In your specific case, replacing the key „en“ with „es“, which would have the effect that it always remains „es“ in subsequent runs.

Luckily, attranslate already has a feature for key-replacements, and the feature is demonstrated in https://github.com/fkirc/attranslate/blob/master/sample-scripts/android_to_ios.sh.

However, doubt that the key-replace-feature is working for YAML files at the moment. I will try it out to see if it works. If not, then I might release an update of attranslate to make the key-replace-feature usable for YAML files.

[fkirc]

Before attranslate gets an update, this would also be fixable with a simple postprocessing script, by invoking that postprocessing in the same script that also invokes attranslate.

For example, something like the following postprocessing script could be used (not tested, taken from ChatGPT):

const fs = require('fs');

const filePath = 'path/to/your/file.yaml';
const searchStr = 'en:';
const replaceStr = 'es:';

fs.readFile(filePath, 'utf8', (err, data) => {
  if (err) {
    console.error(err);
    return;
  }

  const result = data.replace(new RegExp(searchStr, 'g'), replaceStr);

  fs.writeFile(filePath, result, 'utf8', (err) => {
    if (err) {
      console.error(err);
      return;
    }

    console.log(`File "${filePath}" updated successfully.`);
  });
});

[fkirc]

In that sense, this issue is related to https://github.com/fkirc/attranslate/issues/250, since this could also be fixed by a postprocessing script. Essentially, users of attranslate are free to write arbitrary postprocessing scripts to cover such cases. Since attranslate is a NodeJs-program, it makes sense to also write the postprocessing in JavaScript/NodeJs.

[kgorshkov]

Please note the core issue of the ticket:

The issue is that when the first line language code is updated manually (or with a postprocessing script), if attranslate is run again for updates it no longer recognizes that all following sub or indented keys and their translations are existing already-translated lines.

[fkirc]

You are right, it seems that both a „preprocessing script“ and a „postprocessing script“ would be needed to workaround the problem.

For example the following three steps might work:

Preprocess: replace es with en Invoke attranslate normally Postprocess: replace en with es

Anyways, I will consider this for future updates to reduce the necessity of preprocessing and postprocessing.

[fkirc]

During the development of attranslate-V2, I tried to solve your issue via the keyReplace-feature. However, it turned out that the keyReplace-feature did not work correctly with YAML, and it would be over-excessively complex to make it work correctly. So I made the decision to delete the keyReplace-feature from V2, because I do not want to keep half-broken features with dubious value.

To compensate for this loss, I added a new postprocessing-script to the sample-scripts: https://github.com/fkirc/attranslate/blob/master/sample-scripts/search_replace.js

I also expanded the YAML-sample with the following instructions on how to invoke preprocessing/postprocessing: https://github.com/fkirc/attranslate/blob/master/sample-scripts/yaml_ecommerce.sh

I recognize that you might already have solved the issue in your own way, nevertheless I thank you for reporting the issue because it could help future-users of attranslate!