You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
angular-gettext shouldn't be in the business of trying to guess whether to use the JS or HTML extractor on a given file. As it stands, we get feature requests to add support for HTML-like languages all the time. We can leave the existing strategies in place, but the docs should be updated to have people just call extractHtml or extractJs directly.
The text was updated successfully, but these errors were encountered:
I sort of disagree. People shouldn't be bothered with this choice: it should do the right thing automatically if you work according to common sense.
One of the design philosophies I have in mind for angular-gettext is that it's opinionated: we only ask the truly crucial questions. Anything that's optional or unneeded probably shouldn't be there. This leads to a nice property: there's only 1 way of doing things, which should be very easy. If things are hard, you'll probably be deviating from how things should work, which should be a signal that you might want to reconsider things.
If you're the kind of person who likes to do strange things, well... you deserve your world of pain.
angular-gettext shouldn't be in the business of trying to guess whether to use the JS or HTML extractor on a given file. As it stands, we get feature requests to add support for HTML-like languages all the time. We can leave the existing strategies in place, but the docs should be updated to have people just call
extractHtml
orextractJs
directly.The text was updated successfully, but these errors were encountered: