Scan the output of helpers for other helpers, passing in the same page context

[chrisbloom7]

It would he helpful to be able to have helpers who's output includes helpers. For instance, I have a translation helper and in the translations I would like to be able to use another helper that applies a span. As an example, given the following page:

---
subject: You got recognition
i18n:
  congrats:
    es-us: Enhorabuena, ha sido reconocido con {{#primary}}*|POINTS_RECEIVED|* puntos{{/primary}}!
    fr-cs: Félicitations, vous avez été reconnu par {{#primary}}*|POINTS_RECEIVED|* points{{/primary}}!

---
{{#i18n "congrats_1"}}Congratulations, you've been recognized with {{#primary}}*|POINTS_RECEIVED|*{{/primary}} points!{{/i18n}}

The helper outputs

*|IF:LOCALE=es-us|*
Enhorabuena, ha sido reconocido con {{#primary}}*|POINTS_RECEIVED|* puntos{{/primary}}!
*|ELSEIF:LOCALE=fr-cs|*
Félicitations, vous avez été reconnu par {{#primary}}*|POINTS_RECEIVED|* points{{/primary}}!
*|ELSE:|*
Congratulations, you've been recognized with <span class="color-primary">*|POINTS_RECEIVED|*</span> points!
*|END:IF|*

The default translation has the primary helper applied, but the others don't. I could see many use cases for being able to have helpers that output text with other helper tags, which are applied using the same closure context. The only danger I see here is the potential for circular references and falling into an endless loop where helper A outputs text that requires helper B, and B outputs text that requires helper A.

[XmlmXmlmX]

Sound like a similar requirement: #45

[gakimball]

I closed #66, which is a similar request, with an explanation similar to what you've given above:

The only danger I see here is the potential for circular references and falling into an endless loop where helper A outputs text that requires helper B, and B outputs text that requires helper A.

I don't know that there's a sound way to do this the way you're describing. That's because the Handlebars template depends on those Front Matter variables, but with this feature, the Front Matter then also depends on the variables. In a sense it partially depends on itself.

However, your use-case here for i18n is interesting, because that's an obvious instance where metadata becomes dynamic. That being said, I'm not sure if i18n is something Panini will support, since the library is supposed to be fairly minimal and lightweight.

It's not out of the question, though, so let's close this in favor of #45.

[chrisbloom7]

We ended up implementing i18n a bit differently in the end as we started to use OneSky service for our translations across all platforms, including email. So we no longer embed translations in the frontmatter, but use a separate data file now. Thanks for closing the loop on this. I would agree that baked-in i18n seems out of scope for panini since it could be done any number of ways.