Add option to skip template execution

[nohajc]

Hi,

I use your library in production and it works great. Except now I've come to a point where I need it to play nicely with a different string parameter syntax.

Just for context, I'm dealing with a shared repository of localized strings which has multiple consumers using different programming languages and libraries. This already involves conversion from xliff to a format suitable for go-i18n and some of the strings contain placeholders with a C#-like (but simplified) format string syntax (e.g. "arg1: {0}, arg2: {1}, {{escaped}}").

The problem is with escaped curly braces which correspond to parameters in go templates. When I try to localize a string like this, I get en error because it's not even a valid go template.

Therefore it would be very useful if I could just disable template execution and process any string parameters with custom syntax myself.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5257e26) 82.77% compared to head (b4ca9f4) 82.91%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #316      +/-   ##
==========================================
+ Coverage   82.77%   82.91%   +0.13%     
==========================================
  Files          15       15              
  Lines        1730     1744      +14     
==========================================
+ Hits         1432     1446      +14     
  Misses        232      232              
  Partials       66       66              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nohajc]

Btw, I did figure out it's possible to configure custom parameter delimiters, but that still requires using go-style named parameters. This just doesn't work for numeric indices unless I escape any occurrences of double curly braces which basically means turning every {{ into {{ "{{" }} (and the same with }}). I'd say it's better to make the library more configurable rather than using workarounds like this.

[nicksnyder]

Thanks for the clear problem statement and proposed solution. Something I want to consider is making the templating engine itself customizable. Then it would be possible to provide a no-op templating engine (which would solve the problem you have). I am not sure if this can be done in a backward compatible way, but if it can that might be preferable.

[nohajc]

@nicksnyder Would you be willing to merge this before going forward with the more general solution? It would really help me right now... Otherwise I'd probably end up forking the library for the time being.

I mean, the change in public API is rather minimal, it's just one more config option. Of course the no-op templating engine would be a different option but I suppose by then you could just deprecate this one.

[nicksnyder]

There are a few issues that would be solved by making the templating system more flexible, so if we are going to add to the public API, I would prefer to do it in a way that will resolve multiple issues at once. I think I have a solution coded up in #317 but I still need to add some tests to verify.

With that change, instead of NoTemplateExec = true you would use TemplateEngine: NoTemplateEngine{}.

Would that work for you?

[nohajc]

You're fast. :) Definitely, that would work.

[nicksnyder]

With 2.4.0 there is now a way to disable template parsing. Check out the release notes for more info.