Replies: 1 comment 1 reply
-
Thanks for sharing that @simonc. "Prior art" like this in real-world scenarios definitely helps guide our product direction. We're roughly half-way towards a legit I18n solution…some code lurks under the hood to this effect, but there are so many different ways people end up wanting to structure their localized content, it's hard to account for all possibilities simultaneously. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi there 🙂
I know some work and reflection already went into I18n in Bridgetown but I'd like to share a real use-case I've had to solve with Jekyll as I think it could be interesting.
The base idea of translating your content is to have various URLs like
/foo
,/en/foo
and/de/foo
, and serve the content in the proper language.That said, for SEO reasons, you might want to have localized slugs while keeping a relationship between the variants via
<link rel="alternate" ...>
. This creates a lot more complexity as you need a common identifier to link all this together but it's doable.The way I solved it was by giving a shared
ref
key to all variants of a page and alang
property to filter them. Here is a link to the code I used. It's a dirty messy code as I was just aiming for "it works", but at least… it works 😬https://gist.github.com/simonc/f393bba83a992635fb238e62dd84bd0d
As an example, the front matter for one of our doc pages would look like this:
The result can be inspected here https://www.pdfmonkey.io/doc/guides/generate-a-document/
You can see that in the
<head>
tag we have the alternate links, and in the footer we have a dropdown that contains links to the various translations of the current page.I can also provide a gist for the cross-language links if that's useful.
I hope this helps with the whole feature as I think it would be a great one to have in Bridgetown.
❤️
Beta Was this translation helpful? Give feedback.
All reactions