I18n forced to single lang.

[motleydev]

I recently updated the the latest builds of middleman and I can't recall what the previous version was. I have articles with .html.markdown.erb extensions so that I can use an if filter based on the 18n classification to render english content for one page and german content for another but maintain a single file. When I render out article.body it always defaults to the first language, if I only bring in the title - then it remains correct. It's a little confusing to describe because I don't know why it is choosing en as the default lang since default is set to false. It is the first supported lang listed though. Thanks for any help

[motleydev]

Ok, some cleanup after some tests:

• I tried changing the "supported languages" order - no effect.
• I tried removing the erb extension - no effect.
• I tried removing the "en" if wrapper all-together from the article - no effect, just missing content.

I have a return of <%= i18n.locale.to_s %> above my return of the article.body and one below. The one above returns "de" and the one below returns "en." If I return just article.title then it's "de" top and bottom. Thanks for any help.

[bhollis]

Hi @motleydev,

I'm afraid I don't completely understand what the problem is and how to reproduce it. Could you point me at a sample project that shows the bug?

[motleydev]

Hello @bhollis, Sorry for the confusion - I'm not even sure the best way to describe it. Here's a little more longform of what is happening with some code examples.

First, my general setup is a midleman site with i18n support for "en" and "de."

On my homepage I have a slider that uses the middleman-blog feature for my slide content.

To incorporate the multi-langual system I use an if argument in my article so that I can deliver either english or german content on build.

For example, here's a sample structure:

---
title: data
other: data
---

<% if I18n.locale.to_s == "en" %>

I speak English.

<% elsif I18n.locale.to_s == "de" %>

Ich spreche Deutsch.

<% end %>

To fully support this I used the kramdown library for my markdown engine and used erb as the layout engine.

Here's the bit from my config.rb

require "kramdown"
set :markdown_engine, :kramdown
set :markdown, :layout_engine => :erb
set :kramdown, :parse_block_html => true

My file name convention then runs like: date-title.html.markdown.erb

This all worked perfectly until recently - which, I realized, was roughly the time when either middleman-blog or middleman-core received an update and I had incorrect gemfile dependencies set to use either version x or newer.

I fixed the problem by setting a hard lock on the gem files and here is a sample from the Gemfile:

Note, this is a passing Gemfile structure, with everything set to the latest is when it breaks.

gem "middleman", "3.0.11"
gem "middleman-livereload"
gem "middleman-blog", "3.1.1"
gem "zurb-foundation", "~>3.2.0"
gem "kramdown", "~> 0.13.8"
gem "middleman-sync", "~> 3.0.5"
gem "thin"
gem "rack-contrib"
gem "middleman-minify-html"
gem "utf8"

The symptom I was experiencing was that every time I ran a server or build it would only return the english article.body into my template. As a test, I set up the following structure in my loop:

<%= I18n.locale.to_s %>
<%= article.body %>
<%= I18n.locale.to_s %>

which renders, on a german page:

de "lorem ipsum" en

If I render out:

<%= I18n.locale.to_s %>
<%= article.title %>
<%= I18n.locale.to_s %>

it returns:

de "Lorem Ipsum Title" de

I've included everything because some of this is middleware which may be causing a problem and because I also just don't know enough to know what might be causing an interaction problem. I'm really just dabbling. I'm supposed to be in Photoshop right now. :)

Thanks for any help.

[bhollis]

I think there's a similar bug filed against the main middleman bug tracker. I don't thing this is a blog extension problem.