-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional options #65
Comments
The general idea is that While I think xgettext-template should stay true to that idea, there might be room to move things out of this project and into another one or into the parsers. Thinking out loud here: There is also the parser integration. Currently these are dependencies, but maintenance of those is ugly. |
Regarding using xgettext inside a script instead as a CLI tool: It can be solved by adding an explanation to the README.
Regarding additional functionality. We could allow non-standard parameters only to be used when using the procedure above (through passing a xgettextOptions object). However, the two additional features I asked about can be implemented separately. But I do believe that integrating it with I don't know much easier it will be to maintain parsers if they are not implemented as dependencies. Maybe writing a specification document on how parsers should format the parsed strings and what should they prepare can ease the maintenance a bit (and development of new parsers). Just throwing ideas here. |
It seems like a good idea to have this discussion here as it can be useful to others.
@eldarc wrote:
The text was updated successfully, but these errors were encountered: