arrays and front-matter variables about grunt-assemble-i18n

[LaurentGoderre]

I think you need to do fruits: <%= i18n[language].fruits %>.

[eikawata]

That also does not work.

In my case, I have an array of objects stored in an external file as follows.

books.yml

books:
  - book:
      - title: Book Foo
      - description: foo foo
  - book:
      - title: Book Bar
      - description: bar bar

I want to do {{#each}} on the array inside Handlebars template, so I did

---
books: <%= i18n[language].books %>
---

{{#each books}}
  <h2>{{ book.title }}</h2>
  <p>{{ book.description }}</p>
{{/each}}

This #each helper just outputs an empty block, without even rendering <h2> or <p>. But I noticed that if I do {{#each en.books }} ... {{/each}} (without using YFM), it works fine. Isn't this a bug?

By the way, having to define a variable in YFM for each array I want to use is really cumbersome. It'd be nice if we could do something like just i18n.books.

[LaurentGoderre]

The issue is that sometimes you need a string in a specific language, not necessarily the language of the page, that's why it is the way it is but we could have another variables to point to the current language object. Any idea?

[jonschlinkert]

@LaurentGoderre out of curiosity, in your projects, is there something you can point me to that shows how the languages created/formatted or otherwise converted to data so they can be used in templates as context?

[LaurentGoderre]

We use a CSV that is then converted to the right data

https://github.com/wet-boew/wet-boew/blob/master/src/i18n/i18n.csv
https://github.com/wet-boew/wet-boew/blob/master/Gruntfile.coffee#L1263-L1274

[LaurentGoderre]

Although I would much prefer to handle this through Transifex

[jonschlinkert]

great, thanks for the info. I'm going to look into it a bit, hopefully I can make some of this easier in assemble.

[LaurentGoderre]

The biggest issue I saw with this and assemble is when using the function like navigation. I had to preprocess the front-matter for all files to make sure the i18n substitution was happening other wise I would get this for the first file

Link 1
i18n(link2)
i18n(link2)
``
And this for the second file:

Link 1
Link 2
i18n(link2)
``

And so on

[jonschlinkert]

yeah, I think that would be expected with front matter in general - since that data won't be on the context until it's actually parsed. with 0.6 this is a lot easier, and we have several options to ensure you don't have that issue anymore. let me know if you want to review sometime