Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option localizable to separate blog articles per locale #355

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

schmidt
Copy link

@schmidt schmidt commented Oct 9, 2017

middleman-blog already supports middleman-i18n, so that blog articles can have locales assigned. This locale can be used in the path. And it is used in the article and layout.

But we were trying to separate the articles in different languages completely, similar to the way the localizable folder in middleman-i18n works. With the following configuration:

activate :i18n
activate :blog do |blog|
  blog.sources = "blog/{lang}/{year}-{month}-{day}-{title}.html"
  blog.permalink = "blog/{title}"
end

we were hoping for the following result:

$ find build/blog
build/blog/first-english-article.html
build/blog/second-english-article.html
$ find build/fr/blog
build/fr/blog/premiere-article-francaise.html
build/fr/blog/deuxieme-article-francaise.html

Furthermore, we wanted to have build/blog.html only list English articles, while build/fr/blog.html should list French articles only (and the same tag pages).

Unfortunately, this cannot be achieved using the current features and configuration options of middleman-blog. There are some discussions within this bug tracker and on the internet, which suggest, using separate blog instances for each language, but then we need to duplicate the calendar and tag templates, because each of these can only belong to a single blog instance.

So I went ahead and extended middleman-blog accordingly. Since the separation of blog articles by locale is a change in behaviour, I decided to activate this feature only when a newly introduced configuration option is set. Since I was aiming at the same path structure, as the one that's generated by middleman-i18n and the localizable folder, I've used blog.localizable = true. Another possible name would have been blog.separate_locales = true.

Please let me know, if you're interested in this feature and if I can do anything to help you review or merge these changes.

Marking feature as @wip since it's not working yet
So that overview pages don't list articles from other languages
Following the configuration of middleman-i18n, blog articles are now prefixes with the proper locale. Articles in the default locale, when mount_at_root is used, remain unprefixed.

This way we're mimicking the schema used for pages in the localizable folder in middleman-i18n enabled apps.
So that they don't list articles from other languages. Also prefixing the paths according to middleman-i18n configuration with proper locale prefix.
@coveralls
Copy link

Coverage Status

Coverage increased (+0.3%) to 93.274% when pulling 75630d6 on planio-gmbh:localizable into fec110f on middleman:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage increased (+0.3%) to 93.274% when pulling 75630d6 on planio-gmbh:localizable into fec110f on middleman:master.

@coveralls
Copy link

coveralls commented Oct 9, 2017

Coverage Status

Coverage increased (+0.4%) to 93.294% when pulling 75630d6 on planio-gmbh:localizable into fec110f on middleman:master.

@passatgt
Copy link

I had some issues with this branch using the blog.prefix parameter. The tags are not generated this way. Specifying the prefix manually in the blog.permalink and blog.taglink does work.

@passatgt
Copy link

Also, trying to link to a tag archive only works on the main langue:

<%= link_to tag.capitalize, tag_path(tag) %>

For every other language, it just displays "#" in the link's href.

Since it was failing randomly with the server, but working properly when run in isolation.
@coveralls
Copy link

coveralls commented Nov 13, 2017

Coverage Status

Coverage increased (+0.06%) to 92.996% when pulling 8edc8b4 on planio-gmbh:localizable into fec110f on middleman:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.04%) to 92.975% when pulling 8edc8b4 on planio-gmbh:localizable into fec110f on middleman:master.

@coveralls
Copy link

coveralls commented Nov 13, 2017

Coverage Status

Coverage increased (+0.4%) to 93.294% when pulling f88cb15 on planio-gmbh:localizable into fec110f on middleman:master.

@schmidt
Copy link
Author

schmidt commented Nov 13, 2017

@passatgt Thanks for taking a look at the proposed changes.

I have just updated the PR to fix tag_path and the corresponding calendar path helpers. This was basically an oversight on my end. Thanks for the pointer.

Could you give me an example of how you wanted to use the blog.prefix option? Then I'll try to take a closer look.

@passatgt
Copy link

passatgt commented Nov 13, 2017

@schmidt so this is my setup:

activate :blog do |blog|
  blog.localizable = true
  blog.prefix = "support"
  blog.permalink = "{title}.html"
  blog.sources = "{lang}/{year}-{month}-{day}-{title}.html"
  blog.taglink = "category/{tag}.html"
  blog.tag_template= 'support-category.html'
  blog.layout = "support-article"
end

Expected to generate /support/category/something/index.html, however this is not generated at all.

Using the config like this, works as expected:

activate :blog do |blog|
  blog.localizable = true
  #blog.prefix = "support"
  blog.permalink = "support/{title}.html"
  blog.sources = "support/{lang}/{year}-{month}-{day}-{title}.html"
  blog.taglink = "support/category/{tag}.html"
  blog.tag_template= 'support/support-category.html'
  blog.layout = "support-article"
end

Thanks for the tag_path update, i'll check it out.

Update: the tag_path update is working 👍

@github-actions github-actions bot added the Stale label Apr 12, 2024
@markets
Copy link
Member

markets commented Apr 15, 2024

ℹ️ This issue is stale because it has been open for more than 90 days with no activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants