untra / polyglot

:abc: Multilingual and i18n support tool for Jekyll Blogs
https://polyglot.untra.io
MIT License
410 stars 59 forks source link

Is there a way to access the page front matter in a specific language? #201

Open george-gca opened 4 months ago

george-gca commented 4 months ago

I've been struggling with this for a while now: related blog posts are not calculated with Latent Semantic Indexer (LSI) for localized blog posts. I've asked for help on Jekyll talk, opened an issue in the classifier-reborn plugin, and left an open issue on my template repo as a reminder of this.

Just now I realized that after I moved from Jekyll Multiple Languages Plugin to Polyglot the related blog posts are at least created with the correct localized link to the post, but not the localized page title. So is there a way to get a localized version of the page given I have access to the original version of it? This way I could get the proper page.title attribute and use the localized page title for the posts. This issue can be seen in any localized blog post in my template demo, at the end of it.

I believe now that having access to the front matter also solves #199.

george-gca commented 4 months ago

Maybe polyglot could export some attributes at the site level, like all_posts or all_pages, this way one could loop through them and find another page with the same page_id (not sure how this would end up working for collections though). Another solution would be to create front matter variables for all the variations of that page in other languages, something like:

Page in default_lang

page_id: aaa
title: a title
description: a description

localizations:
  pt-br:
    title: um título
    description: uma descrição

what do you think? If you give me some pointers I could implement something that would help.

untra commented 4 months ago

is there a way to get a localized version of the page given I have access to the original version of it

I would think the move is to put the data you need on the page in the localization you are working with? If each page needs the data, maybe keep it in _data/ directory so it can be accessed like that? otherwise...

Another solution would be to create front matter variables for all the variations of that page in other languages, something like...

Wouldn't someone have multiple pages in different langs with their own frontmatter? I don't see why the page would have mixed frontmatter values?

Page in default_lang

page_id: aaa
title: a title
description: a description

page in pt-BR

page_id: aaa
title: um título
description: uma descrição

otherwise I think these are values that should live in _data/ if they need to be shared across languages and pages.

george-gca commented 4 months ago

The problem is that the title is coming wrong in my case.

For example, check this page. The related blog posts down below have both the titles and urls in en-us. Now, if you check the pt-br localized version of the same post you can see that all links have the title in en-us (sorry, due to laziness I didn't translate all posts titles, but check the one with title a post with code), but their urls are correctly pt-br. Also if you open the post a post with code you can see that its title is in pt-br.

The code that I use to create this section is here. I simply do a loop

{% for post in site.related_posts | limit: site.related_blog_posts.max_related %}

where these related_posts are calculated with LSI, and use it with:

<a class="text-pink-700 underline font-semibold hover:text-pink-800" href="{{ site.baseurl }}{{ post.url }}">{{ post.title }}</a>
george-gca commented 4 months ago

I am not sure that the LSI is being calculated based on all posts (including other languages) or only in the specified language. But either way, the urls are pointing to the correct localized page while the titles are returning the non-localized ones.