-
Notifications
You must be signed in to change notification settings - Fork 3
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
collecting translations #3
Comments
however static parsing would work if you don't rely on jqtpl tags and its functionality, like this one is done: https://github.com/mashpie/i18n-node but it doesn't make a lot sence then to maintain yet another module. |
yeah, it doesn't. my goal was to reduce visual clutter by registering a custom tag. I personally think I took a look at jqtpl's source, this seems like a safe way to collect strings in dev mode, what do you think?
btw, what is planned for this rewrite? any chance of being able to register a new shortcut, .i.e:
without overwriting
for printf-style formatting, or a way of using
as a shortcut for localized text? any of these would be nice :) |
{{__("text")}} doesn't looks perfect, but it is technically better to use one good template engine independent solution. Statical parsing is also nice then, because it is stable and doesn't force us to collect strings in dev mode, it can be done then like your initial implementation. I don't know details of rewrite of jquery-tmpl, |
I coded this library exactly for template-specific, terse markup. I'm working on just making helpers and template tags available at the user's discretion, no auto-extending, and collecting strings at server start-up. |
static parsing is not a good idea.
Rely on template engine is still a better idea then writing an regex parser, because if engine api will change it is very easy to notify this, then to get different hard understandable errors because of f.e. "space" char on the wrong place. Also it could be possible that "{{" will be customizable in jquery-tmpl later. A big rewrite of jquery-tmpl is comming, so better to rely on api.
Also you need to be able to access translations from js code, so you would need one more parser and this is complicated.
My idea is:
while you are in dev mode, let your translation functino write the string into lang file. You are normally always testing a stuff you want to deploy, so once rendered the page you have all translations collected and if your project is under git, you can even make a diff and see the changes.
The text was updated successfully, but these errors were encountered: