Support of XLIFF format to store translations

[RuslanZavacky]

We want to implement ember-intl for wider usage in our system. As we have quite a substantial amount of data to translate, applications and packages we want to have more information stored alongside with translation strings. Yaml and JSON seems a bit limited in how we can do that.

There is an XLIFF (XML Localization Interchange File Format) format that we want to use to store our translations. This format allows for more customization and is actually a standard for storing translations.

Does anyone have any opinion of adding it to ember-intl?

I'll be able to add implementation for it, but before starting wanted to check if there is no strong preferences why not to add it :)

Thanks!

[jasonmit]

If there's enough interest in additional file types, I'd be happy to add this to ember-intl.

However, this is something that can be implemented in userland using treeForTranslations. This way you're not blocked on waiting for this to officially land in ember-intl.

Basically, you'd write an addon/in-repo-addon that implemented treeForTranslations and reads your host project/parent app XLIFF files and transforms them into json or yml files which then gets processed by ember-intl at build time.

This could be published as ember-intl-xliff - happy to help with it.

Related #595

[RuslanZavacky]

Thank you @jasonmit, I'll try to implement it separately, and see how far I'll get. If something, will ask for help :)

[jasonmit]

Here's an example of an addon that reads .properties files as JSON & writes them to ember-intl as JSON. This should hopefully be enough to get you started. I left some notes where you'll want to make some adjustments.

// addon's index.js
const fs = require('fs');
const path = require('path');
const funnel = require('broccoli-funnel');
const CachingWriter = require('broccoli-caching-writer');

module.exports = {
  name: require('./package').name,

  treeForTranslations(/* translationTree */) {
    // Note: this is telling broccoli to grab all the **/.properties under
    // the parent (addon or app) root directory named `properties`.
    // Putting non json or yml files under "localization" will spit out warnings
    // which you probably don't want.  Future bug fix perhaps.
    const propertiesTree = funnel(path.join(this.parent.root, 'localization'), {
      include: ['**/*.properties'],
      allowEmpty: true
    });

    return new PropertiesTransform(propertiesTree);
  }
};

class PropertiesTransform extends CachingWriter {
  constructor(inputNodes, options = {}) {
    super([inputNodes], {
      annotation: options.annotation
    })
  }

  // Note: you can return a promise here if you're xliff transformation logic contains async behavior
  build() {
    for (let filename of this.listFiles()) {
      const baseFilename = path.basename(filename, '.properties');
      const destFilepath = path.join(this.outputPath, baseFilename + '.json');
      const rawFileContents = fs.readFileSync(filename);

      // TODO: implement your `properties` to JSON transformation logic here.
      // In this example I'm just parsing the contents as JSON since that's
      // what I put inside my example `.properties` files out of laziness
      const translationsAsJson = JSON.parse(rawFileContents);

      // Write it back as JSON since that's what ember-intl supports
      fs.writeFileSync(destFilepath, JSON.stringify(translationsAsJson));
    }
  }
}

[RuslanZavacky]

That's awesome, thank you @jasonmit 👍

[sandstrom]

I'm doing some issue gardening 🌱🌿 🌷 and came upon this issue. Maybe we could move this over to the discussions. There is support (in discussions) to e.g. vote up/down on various feature requests.

By closing some old issues we reduce the list of open issues to a more manageable set.