Tracking file path references for each key

[emmagamma]

(I opened a related issue for the i18next-parser here: i18next/i18next-parser#55)

tldr:

Wanting to add the functionality to track file path references to each key for the purpose of having those comments end up in .po files for our translators to get better context as-needed, requiring modifications both in this repo and in the i18next-parser, and curious how amenable you'd be to merging that sort of thing in?

---

long form:

I've been helping with some efforts to internationalize a medium-large size Ember app, and since gettext doesn't play nice with html and handlebars, we needed these two repos to generate our translation strings and convert between .json -> .po and vice versa.

But we ran into a slight issue, our translators will need file path references for each key, as comments in the .po files (something that gettext does by default in a typical i18n workflow, except gettext has line numbers, which we won't be needing) and although this repo does have some* ability to add comments, the data structure output by the parser doesn't keep track of those file paths.

Initially I modified the i18next-parser to output something that looks more like:

{
  'some key': {
    msgstr: '',
    paths: ['app/templates/error.hbs', '../fake/path']
  }
}

Where paths is an array of each file path location that a given key is found at, in case you have the same key in multiple places in your source code.

rather than the current output:

{
  'some key': ''
}

and I modified the gettext-converter to handle both formats dynamically while converting from .json -> .po, so you can have keys with file path information and others without, in the same file.

Currently, my little demo of this working involves either symlinking my local changes or pointing our app at my own forks of these two repos, which is less than ideal. I'm hoping to get these changes merged in at some point, so in the past couple days I've gone through and modified my code in the parser to use an additional flag '-t, --track-paths', so it generates the original data structure unless you include that flag and set it to true.

To further support our workflow, since the i18next runtime still needs the original format, I also made it so that using '--track-paths' will prepend '/tmp' to the output location of the translation file but not the translation_old file. So rather than running the parser to get our .json, and then running this tool to get our .po - we are running the parser with --track-paths true to get our new .json format, then running this tool on the output /tmp/locales/en/translation.json to get our .po file, and finally running this tool a second time to go from .po -> .json so that we're back in the original format, and now back in the correct directory as well.

Ideally we'd like to merge these changes back into the repos, rather than maintaining our own forks. I'm doing my best to ensure that this is all opt-in behavior and that it doesn't affect any other workflows that people may be using. Just wanted to put the feelers out there before I get my PR's up. Any feedback is appreciated!

[jamuhl]

Personally i passed over maintenance to @perrin4869. No idea how he thinks about this addition.

[perrin4869]

@sourceRS I will be happy to merge this after looking at the PR, I guess it can be useful to the community :).
@jamuhl any opinions on this?
Thanks!

[jamuhl]

i'm for a merge...as long we stay backward compatible.

[emmagamma]

awesome, thanks @perrin4869!
yeah, @jamuhl that is my goal :)
PR's coming shortly