{"action":"created","issue":{"url":"https://api.github.com/repos/zaach/jsxgettext/issues/82","labels_url":"https://api.github.com/repos/zaach/jsxgettext/issues/82/labels{/name}","comments_url":"https://api.github.com/repos/zaach/jsxgettext/issues/82/comments","events_url":"https://api.github.com/repos/zaach/jsxgettext/issues/82/events","html_url":"https://github.com/zaach/jsxgettext/issues/82","id":49681018,"number":82,"title":"project overlap / parser separation","user":{"login":"smhg","id":2411348,"avatar_url":"https://avatars.githubusercontent.com/u/2411348?v=3","gravatar_id":"","url":"https://api.github.com/users/smhg","html_url":"https://github.com/smhg","followers_url":"https://api.github.com/users/smhg/followers","following_url":"https://api.github.com/users/smhg/following{/other_user}","gists_url":"https://api.github.com/users/smhg/gists{/gist_id}","starred_url":"https://api.github.com/users/smhg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/smhg/subscriptions","organizations_url":"https://api.github.com/users/smhg/orgs","repos_url":"https://api.github.com/users/smhg/repos","events_url":"https://api.github.com/users/smhg/events{/privacy}","received_events_url":"https://api.github.com/users/smhg/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2014-11-21T10:29:25Z","updated_at":"2015-03-16T20:31:44Z","closed_at":null,"body":"I've been working on [xgettext-template](https://github.com/gmarty/xgettext) for a while, which seems to be very similar to this project.\r\nI haven't looked into things enough to see what's different (besides language support), so I'm avoiding the overlap-subject for now.\r\n\r\nI came here with this question: since I was working on Swig-parsing, I wondered if you would consider splitting up the parser(s) into different (a) sub-project(s)?\r\nxgettext-template was recently restructured with that in mind: the [Handlebars parser](https://github.com/smhg/gettext-handlebars) is a separate project that can be used independently from the main project (basically the CLI interface). Definitely feel free to use it (it doesn't rely on regex's, but on the Handlebars lib itself)."},"comment":{"url":"https://api.github.com/repos/zaach/jsxgettext/issues/comments/81922341","html_url":"https://github.com/zaach/jsxgettext/issues/82#issuecomment-81922341","issue_url":"https://api.github.com/repos/zaach/jsxgettext/issues/82","id":81922341,"user":{"login":"beck","id":154988,"avatar_url":"https://avatars.githubusercontent.com/u/154988?v=3","gravatar_id":"","url":"https://api.github.com/users/beck","html_url":"https://github.com/beck","followers_url":"https://api.github.com/users/beck/followers","following_url":"https://api.github.com/users/beck/following{/other_user}","gists_url":"https://api.github.com/users/beck/gists{/gist_id}","starred_url":"https://api.github.com/users/beck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/beck/subscriptions","organizations_url":"https://api.github.com/users/beck/orgs","repos_url":"https://api.github.com/users/beck/repos","events_url":"https://api.github.com/users/beck/events{/privacy}","received_events_url":"https://api.github.com/users/beck/received_events","type":"User","site_admin":false},"created_at":"2015-03-16T20:31:44Z","updated_at":"2015-03-16T20:31:44Z","body":"I just started diving into this project have a bit to add:\r\n\r\n> use the template language's parser/lexer if possible\r\n\r\n:+1: \r\n\r\n> I think a parser needs to accept a keyword spec ... template string. \r\n\r\nThere's already an implicit API for how a parser is interfaced, two arguments are sent:\r\n\r\n1. `sources` - a dictionary of `{\"file1.js\": \"content\", \"file2.js\": \"content\", ... }`\r\n1. `options` - all config passed in via the command line (including `keyword`)\r\n\r\nI think this is a good starting point for CLI > Parser communication.\r\n\r\nAs for the response, this is where this project needs some improvement:\r\n\r\nCurrently the response is:\r\n\r\n1. `sources`: a dictionary of filename / **javascript source**\r\n1. `options`\r\n\r\nI propose that the `sources` dictionary does not return javascript but a dictionary of translations [as spec'd by the gettext-parser](https://github.com/andris9/gettext-parser#translations).\r\n\r\nI think this would yield significant cleanup, including:\r\n* Javascript parsing is factored out of `jsxgettext` and moved into it's own `javascript.js` under `lib/parsers/`\r\n* The responsibility of `jsxgettext.js` become more precise: interfacing with parsers and `cli.js`\r\n* Files would no longer be parsed twice (once as their own language, then again as js)\r\n* Parsers become simplified as they no longer have to coerce messages into valid js gettext arguments\r\n\r\n> Updating the CLI package every time a new parser is added or a new version is released, feels so troublesome\r\n\r\nTrue, but it is not too bad.\r\n\r\nIf all are in agreement about proposed changes, then focus should be on refactoring and developing the internal API.  Once that's done, then focus can be on user extensibility with installable parsers."}}