-
Notifications
You must be signed in to change notification settings - Fork 0
Adding localization options to posts
model
#239
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
base: develop
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for padp-staging ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for gbof-c19nyc-staging ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for juel-staging ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for pss-scavenger-hunt ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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 |
Agree, it would be great if any page could be routed via |
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 |
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? |
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
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.
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? |
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. |
Okay, after further discussion, updated the PR to be consistent across the different models. This involves the following changes:
|
7301142
to
addde41
Compare
const locales = config.i18n.locales; | ||
const paths = await fetchPaths(); | ||
for (const lang of config.i18n.locales) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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...)
There was a problem hiding this comment.
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. 👍
src/pages/[lang]/paths/index.astro
Outdated
</h1> | ||
<Cards> | ||
{ _.map(paths, (path) => ( | ||
{ paths?.length ? _.map(paths, (path) => ( |
There was a problem hiding this comment.
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) && (...) )
tina/content/templates.ts
Outdated
@@ -0,0 +1,143 @@ | |||
import TinaMediaPicker from '../components/TinaMediaPicker'; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! 👍
In this PR
Adds the ability to specify different

title
andbody
content for a post for each configured language. In TinaCMS, this will show up below the mainrich-text
field when creating the post, with one bar for each language other than the default: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.