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:
|
ajolipa
force-pushed
the
RB-content-i18n
branch
from
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.
This looks like re-formatting? Any reason for this change?
There was a problem hiding this comment.
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.
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.
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.
Can this be moved back into the content collections? It looks like only two fields are shared between the two.
|
@ajolipa - Checking in on the status on this PR. Is this still something we want to get in? |
Maybe a question for @absempere ? If I recall correctly we ended up not being sure what schema we want for this and possibly decided to hold off on it until we had a clearer sense of what's desired, but I don't totally remember. |
|
Missed this earlier, but yes -- trying to have as much bilingual support as possible. |
5 participants
In this PR
Adds the ability to specify different
titleandbodycontent for a post for each configured language. In TinaCMS, this will show up below the mainrich-textfield 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.