#How to avoid duplicate files for each language

14 messages · Page 1 of 1 (latest)

livid flint
#

I'm currently trying to figure out how to have a localized site with as little template duplication as possible.

I started down the road of using [lang] as the top level folder in pages, but we don't want the primary language to be in a folder. Is there a solution to this beyond having top level templates and templates in [lang] duplicated? Currently, the best I've come up with, is to have most of the contents of those files in a separate component so that I only have to duplicate the stubs, but it seems like there must be an easier way.

For context, we're pulling content from the datocms API to generate the actual pages, and we're using [...slug] templates to do that, similar to if we were using a content collection.

livid flint
#

Figured out that if I do [...lang] instead of [lang], I can have an undefined option that allows building the default language at the top level. Score! Now to figure out how to get the slug template working inside that structure.

real lotus
#

If you're using default "static" mode (SSG), then [...slug].astro should have a getStaticPaths() that maps through all langs AND posts to generate ALL the pages.

livid flint
#

Does that replacing needing the getStaticPaths() in the lang folder index, or is that still required to build the language folders?

#

My problem currently is figuring out the right syntax to get all of that generated inside the [...slug].astro template.

And no, currently I'm taking an SSR mode api build and trying to add this stuff, but we really want to go hybrid eventually (SSR for previews, SSG for production).

#

Well, I think I might mostly be there for SSR. Adding back in the static stuff may be complicated still.

#

just need to fix my graphql queries to pull the correct localized data

real lotus
#

OK. Are you doing something like: src/pages/blog/[...lang]/[...slug].astro then?
You'll have to grab both the lang and the slug from Astro.params, get the right data and render the results.

livid flint
#

right, that's what I'm doing. I ran into some confusion which I think is mostly around the Dato CMS API. Once I get that figured out, I think I'll be able to get the rest of this figured out. Thanks for your help.

livid flint
#

Pretty much have it nailed down, although eventually I'm going to have to learn how to support a true hybrid. SSR only for now. If I add all the getStaticPaths stuff for the SSG, that gets ignored for SSR, so as long as I leave the current code in, does that mean SSR is going to still work?

real lotus
#

I'm not sure that what you are doing is possible, you should probably just try out a simple example (proof of concept), before getting in too deep.

You may also be interested in looking at something like this:
https://developers.netlify.com/guides/how-to-do-advanced-caching-and-isr-with-astro/

Incremental Static Regeneration (ISR) is a powerful pattern for rendering pages on the web. Astro has useful tools to do fine-grained ISR and other advanced caching patterns when deployed to Netlify. This guide will show you how to do it.

livid flint
#

So basically instead of SSR/SSG hybrid, it's SSR with long caching to fake SSG?

real lotus
#

Yeah, kind of a best of both worlds type approach.

  • If you rebuild, the cache is gone and you start over, so you won't get stale pages.
  • You save long build times, if you have lots of pages.
  • You get static-like performance, after the initial page build.
livid flint
#

Thanks, I'll look into it!