Skip to content
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

Open
kof opened this issue May 1, 2011 · 4 comments
Open

collecting translations #3

kof opened this issue May 1, 2011 · 4 comments
Milestone

Comments

@kof
Copy link

kof commented May 1, 2011

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.

@kof
Copy link
Author

kof commented May 2, 2011

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.

@ricardobeat
Copy link
Owner

yeah, it doesn't. my goal was to reduce visual clutter by registering a custom tag. I personally think {{__("text")}} is awful.

I took a look at jqtpl's source, this seems like a safe way to collect strings in dev mode, what do you think?

open: 'if($notnull_1){i18n.strings[$1a] = "";_.push($.escape($1a));}'

btw, what is planned for this rewrite? any chance of being able to register a new shortcut, .i.e:

_e{"text"}

without overwriting .template, or having access to both strings in

{{e "one", "two"}}

for printf-style formatting, or a way of using

{{"text"}}

as a shortcut for localized text? any of these would be nice :)

@kof
Copy link
Author

kof commented May 5, 2011

{{__("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,

@ricardobeat
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants