Skip to content

Conversation

ajolipa
Copy link
Contributor

@ajolipa ajolipa commented Sep 4, 2025

In this PR

Adds the ability to specify different title and body content for a post for each configured language. In TinaCMS, this will show up below the main rich-text field when creating the post, with one bar for each language other than the default:
image

On the front end, the localized title and body will be used if they exist, and otherwise the title and body for the default language will be used.

Copy link

netlify bot commented Sep 4, 2025

Deploy Preview for padp-staging ready!

Name Link
🔨 Latest commit 845cde7
🔍 Latest deploy log https://app.netlify.com/projects/padp-staging/deploys/68c9a4ee81b78100086f2aa8
😎 Deploy Preview https://deploy-preview-239--padp-staging.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Copy link

netlify bot commented Sep 4, 2025

Deploy Preview for gbof-c19nyc-staging ready!

Name Link
🔨 Latest commit 845cde7
🔍 Latest deploy log https://app.netlify.com/projects/gbof-c19nyc-staging/deploys/68c9a4ee8b63a50008fe3055
😎 Deploy Preview https://deploy-preview-239--gbof-c19nyc-staging.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Copy link

netlify bot commented Sep 4, 2025

Deploy Preview for juel-staging ready!

Name Link
🔨 Latest commit 845cde7
🔍 Latest deploy log https://app.netlify.com/projects/juel-staging/deploys/68c9a4ee38d78300080c1fd2
😎 Deploy Preview https://deploy-preview-239--juel-staging.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Copy link

netlify bot commented Sep 4, 2025

Deploy Preview for pss-scavenger-hunt ready!

Name Link
🔨 Latest commit 845cde7
🔍 Latest deploy log https://app.netlify.com/projects/pss-scavenger-hunt/deploys/68c9a4eeca7a0c00089032da
😎 Deploy Preview https://deploy-preview-239--pss-scavenger-hunt.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@ajolipa ajolipa requested a review from dleadbetter September 4, 2025 01:45
@dleadbetter
Copy link
Contributor

Is there a reason we don't want to keep localization for posts/paths consistent with the way we're doing it for pages? (e.g. allowing users to create folders /en/My-Awesome-Post.mdx).

@jamiefolsom
Copy link
Member

Is there a reason we don't want to keep localization for posts/paths consistent with the way we're doing it for pages? (e.g. allowing users to create folders /en/My-Awesome-Post.mdx).

Agree, it would be great if any page could be routed via /[lang]/whatever/path, unless there are compelling alternatives.

@ajolipa
Copy link
Contributor Author

ajolipa commented Sep 4, 2025

Is there a reason we don't want to keep localization for posts/paths consistent with the way we're doing it for pages? (e.g. allowing users to create folders /en/My-Awesome-Post.mdx).

When Anindita and I discussed it we both felt it was a more intuitive user experience to be able to add localized content directly to a specific post rather than having to create a new file for every language for every post. The effect on the routing is the same, with the difference that the slugs aren't localized I guess -- the Spanish version of a post (or whatever) is at /sp/posts/[slug]. I do think this structure gives a better user experience, but not by a huge factor, so if the consensus is to change it then I'll change it. @absempere any thoughts?

@absempere
Copy link

In terms of translation, it's much easier to translate on the same page instead of having to switch between browser tabs or windows. Given the number of blog posts that could be added, seems like a lot to redo an entire folder of posts multiple times.

It'd be helpful to have localized post titles if possible. It seems a bit odd to have an English title/URL and Portuguese text.

One question: does this mean that every post will have to have an English version? Is it possible to have a post that's only in Spanish, or would that post then have to be a page?

@ajolipa
Copy link
Contributor Author

ajolipa commented Sep 4, 2025

In terms of translation, it's much easier to translate on the same page instead of having to switch between browser tabs or windows. Given the number of blog posts that could be added, seems like a lot to redo an entire folder of posts multiple times.

Hmm... that makes sense but the way this method works out you're still translating in a different tab, since you have to click through to e.g. the sp object and then enter the title and body. I suppose it would be possible to do a flattened version where all of the different language fields appeared on literally the same page, but then I'd have to update the logic for fetching the localized content on the consuming end... 🤔

It'd be helpful to have localized post titles if possible. It seems a bit odd to have an English title/URL and Portuguese text.

With this set-up the slug isn't localized but the title is. I think there are fancy ways to make like aliases so that the user could add a localized slug and it would display in the URL bar if available, but I'd have to look into that further. This is how we've done it for other sites like MiCA, having the title localized and the slug fixed.

One question: does this mean that every post will have to have an English version? Is it possible to have a post that's only in Spanish, or would that post then have to be a page?

Easy enough to filter out posts with empty title and/or body from the index, so then if a post has no English content it wouldn't show up if you're set to English. What user experience do we want if e.g. you're set to a non-default language and go to the posts index? Should you only see posts that have content in that language? My assumption was you should still see all the posts, with default language text where no localization exists, but is that wrong?

@dleadbetter dleadbetter added the v1.4.0 Issues in v1.4.0 label Sep 11, 2025
@dleadbetter
Copy link
Contributor

Bumping this before it falls off my radar: My concern with this implementation is that we will now have two different ways to localize content: Pages use a directory based method, while posts use a field based method. I'm indifferent about which method is used, but I think it should be consistent across the different content collections.

I chose the directory based method for pages because it simplifies the Tina schema by not requiring additional fields per locale.

Also, maybe out of scope for this task, but we should probably also localize paths for completeness.

@dleadbetter dleadbetter added next release Issues in the next release and removed v1.4.0 Issues in v1.4.0 labels Sep 12, 2025
@ajolipa
Copy link
Contributor Author

ajolipa commented Sep 15, 2025

Okay, after further discussion, updated the PR to be consistent across the different models. This involves the following changes:

  • Adding the ui.allowedActions.createNestedFolders: true parameter to the models with localized content; without this flag set, I was observing the behavior that I would create a folder via the Tina interface and then not be able to access it or its content.
    • Question: Does this now allow too much freedom? Was that flag not set to true because we want to create all of the necessary localization folders during initial setup and not allow users to add them? I played around with just creating the folders in the content repo but still wasn't seeing them show up in the CMS though.
  • Changing localize_pages to localize_content in the config file. The downside of this is backward compatibility obviously but I think the number of sites affected is pretty small and the old name felt misleading if it's actually controlling the setup for pages, paths, and posts. Open to being talked out of it though.
  • The pages in the navigation no longer default to the default locale pages if the current locale has none. This matches the desired behavior with paths and posts. The home page will still default to the default locale if necessary.

const locales = config.i18n.locales;
const paths = await fetchPaths();
for (const lang of config.i18n.locales) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like re-formatting? Any reason for this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure how _.each plays with async functions so I just changed it to match how we're getting the static paths here, since we need to fetch paths for each locale separately. (Or is the re-formatting you're referencing something smaller? Definitely possible that some auto-formatting slipped through my notice; VSCode likes to forget that I told it not to auto-format on save...)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, I see. fetchPaths now requires the locale to be passed as an argument. That makes sense. Yes, good call switching to for, _.each does not handle async requests. 👍

</h1>
<Cards>
{ _.map(paths, (path) => (
{ paths?.length ? _.map(paths, (path) => (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ternary operators in JSX make things hard to read. Could we do something like:

( !_.isEmpty(paths) && (...) )
( _.isEmpty(paths) && (...) )

@@ -0,0 +1,143 @@
import TinaMediaPicker from '../components/TinaMediaPicker';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be moved back into the content collections? It looks like only two fields are shared between the two.

@ajolipa ajolipa requested a review from dleadbetter September 16, 2025 17:59
Copy link
Contributor

@dleadbetter dleadbetter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 👍

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

Successfully merging this pull request may close these issues.

4 participants