-
-
Notifications
You must be signed in to change notification settings - Fork 364
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
request: {{i18n "path/to/file"}} #66
Comments
I was thinking about something like that and was struggling with the concept a bit. The current approach requires on file per language so I assume that "path/fo/file" is rather "folder/to/file" right? I have a separate branch were I was experimenting with scoped i18n which basically is the same thing as you are mentioning. If there is a way to load a file from a folder from the helper it probably be more effective than my approach. |
Is there another helper I can base myself off that does this kind of stuff? I want to try and adopt conventions whenever possible. |
@doowb and I will work on putting something, would you mind creating an issue to request it so we can track progress against it?
Yes, there is. Really, a single helper could do just about anything that the average grunt task can do. So if you really wanted to go crazy you could replicate an entire build process from a single helper... not that you should, but just to make the point. So, for example, if you needed to you could copy files from folder A to folder B: Handlebars.registerHelper("copy", function(a, b) {
return grunt.file.copy(a, b);
}); Another example of what helpers can do is Again, these are just examples to illustrate that helpers can be very powerful. |
Can assemble be run without grunt though? Shouldn't I aim to make autonomous? |
Currently no, but we're planning a refactor of assemble and anything is possible for the future. we would love for you and your team to participate in this planning process here: https://github.com/assemble/refactor-planning. Sincit it's new, currently it's just some notes and placeholder files, but we want to start adding issues and having discussions regarding goals for the next major version of assemble.
Well, that's your call, but IMO it's best to create the helper that you need for the job your doing. We're planning on labeling helpers somehow to make it easy to differentiate them based on the following:
and so on... Not all of this is documented (since it's new), but assemble now allows you to add helpers from node_modules by simply adding the name of the helper module to your devDependencies and then adding the same name to the But since assemble makes it so easy to add helpers we've decided to do the following:
So, for example, continuing the point about adding helpers from node_modules and using minimatch patterns, let's say your project uses 25 different helpers that each exists in a separate npm module. if they all follow a common naming convention, such as options: {
helpers: 'helper-*'
} Or, IMO the better way to go would be to publish a npm package with a custom "collection" that really only consists of an index page that requires in the helpers you want to use. then just refer to that collection in assemble. So I guess IMHO helpers are so easy to create, change and maintain that if you switch to another framework or stop using Grunt altogether we can either: a. modify the helper or create another version that uses minimatch or other libs that don't require Grunt And I'd be happy to help explore other options if it helps make things easier for you and your project. |
closing due to inactivity. please reopen if it still needs to be addressed |
It would be nice to optionally use the helper as a block expression or to include external files.
Maybe @LaurentGoderre would be interested in adding this?
The text was updated successfully, but these errors were encountered: