grunt-assemble-i18n icon indicating copy to clipboard operation
grunt-assemble-i18n copied to clipboard

arrays and front-matter variables

Open thedamon opened this issue 9 years ago • 9 comments

I have this set up so that I can call strings with the i18n helper, but I need to figure out how to handle front-matter variables on a page, and iterating over arrays of data.

Is there a standard/assumed way of doing this?

I want to achieve something like the following:

en:
  title: Bananas
fr:
  title: Les bananes

---
{{title}}

This of course overwrites the en/fr variable so all the other keys are lost and the build fails. My assumption is I need to set these translations in the i18n\en.yml etc?

Then how do I handle, say, an array in my data using {{each}}? I can't pass a helper to a helper


fruits:
-
  name: apple
  color: red or green
  size: medium
-
  name: banana
  color: yellow
  size: medium
-
  name: blueberry
  color: blue
  size: small
{{#each fruits}}
  {{name}}
{{/each}}

Is the key to do fruits: <%= i18n.fruits %> in the front-matter? that doesn't seem to be working...

thedamon avatar Jul 02 '15 16:07 thedamon

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

LaurentGoderre avatar Jul 02 '15 17:07 LaurentGoderre

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.

eikawata avatar Sep 27 '15 10:09 eikawata

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?

LaurentGoderre avatar Sep 28 '15 13:09 LaurentGoderre

@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?

jonschlinkert avatar Sep 28 '15 16:09 jonschlinkert

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 avatar Sep 28 '15 17:09 LaurentGoderre

Although I would much prefer to handle this through Transifex

LaurentGoderre avatar Sep 28 '15 17:09 LaurentGoderre

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

jonschlinkert avatar Sep 28 '15 18:09 jonschlinkert

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

LaurentGoderre avatar Sep 28 '15 18:09 LaurentGoderre

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

jonschlinkert avatar Sep 28 '15 19:09 jonschlinkert