Thank you, @lacco! I'd love to know more about your use-case for this feature.

Sure, I am currently using i18n-tasks and https://github.com/local-ch/i18n-docs in one project which is quite a hassle (need Google Translate and CSV import/ export). My idea is to write my own i18n-tasks command that does the CSV import/ export things to get rid of i18n-docs. If I am successful, I'll definitely let you know, perhaps it might sense to integrate it or at least to add it to the wiki.

Great, thanks! The Wiki would be a great starting point for integration. The best way to integrate a new format is to add an adapter just like the ones for JSON and YAML, and register it via I18n::Tasks::Data::FileSystem.register_adapter and in the option parser.

Oh, I didn't thought of a custom adapter since I still want to store the files in YAML. My use case in particular is that I only want to export to CSV from time to time so that an external translator can deal with the translations, and I need a way to import this CSV back into the app. I think a custom task is still the way to go, right?

i18n-tasks chooses the adapter based on the file extension, so you can store files in any or even multiple formats. Most commands accept a format option, e.g.:

$ i18n-tasks data -fjson

Adding an adapter means automatic support for that format with all the commands:

$ i18n-tasks missing -fcsv > missing.csv            # generate a csv
$ cat translated.csv | i18n-tasks data-merge -fcsv  # import a csv

Okay, my first (and very successful) approach is now using a custom command: https://gist.github.com/lacco/00967844e0c4fdd7c827

I am still not sure why an adapter might be better, I'll dig into this the next few days. Just to give you a little more background, I am trying to convert something like

en:
  header: Hello
  footer: Goodbye
de:
  header: Hallo
  footer: Tschüss

to

I didn't realize you want to use the routing -- the custom tasks are definitely the way to go. Based on this use case, I will refactor a bit the way the adapters work (use actual class, #parse returning a tree instead of a nested hash), so perhaps it's best for you to not implement one just yet.

Please post it to the wiki when you can 👍

@lacco I've gone ahead and posted it to the wiki