-
Notifications
You must be signed in to change notification settings - Fork 187
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
feat(core): add Internationalization to Catalyst #463
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
9 Ignored Deployments
|
Great start. I notice you're adding the functionality around internationalized routes e.g. I think a good step on the way to that could be picking the locale based on the From there, we could layer on end-to-end translation inclusive of localized paths once we have catalog translations in GraphQL and know how URLs are going to work. WDYT? |
@@ -67,7 +72,7 @@ export default async function Brand({ params, searchParams }: Props) { | |||
|
|||
<section aria-labelledby="product-heading" className="col-span-4 lg:col-span-3"> | |||
<h2 className="sr-only" id="product-heading"> | |||
Products | |||
{t('products')} |
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.
in cases like this can I supply a default inline? something like
{t('products', default='Products')}
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.
My 2cents. {t('products', default='Products')}
similar approach is used in the bcapp, where we write source phrase directly in the code.
Pros: when adding a new phrase - it is easier to jump to one file
Cons: to extract translations we have to write more complicated code, iterate over AST tree. + we have to add some rules like : default value should not be a variable or expression
{t('products')}
- used in checkout, themes, bmp, a-a services.
Pros: Much easier to extract phrases, less error prone mechanism
Cons: adding new phrase require developers to open a dictionary
file.
From my point of view {t('products')}
seems good.
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.
next-intl
is probably the only nextjs/i18n library that supports both pages
and app
routers. And it uses translation keys instead of original phrases inline, that of course provides better developer experience.
@bookernath I think we need to sacrifice one of the requirements, either two routers or original phrases inline. From Localization team perspective translation keys are better, but we can do both.
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.
That's fine, thank you
Yup, this is correct 👍 The plan is to have both the Urls for entities would become available to be localized along with making the entity itself being translatable. will cc @funivan and @BC-krasnoshapka in case they'd want to add something here. |
Thanks. Yeah, I see what you mean. I've updated PR and switched off prefixes in routes for now. We still can return to them when we decide/ready. Here how it works now. What's your thought?🤔 updateLocale.mov |
b654f12
to
6b09c6a
Compare
6b09c6a
to
977e3d0
Compare
097429c
to
058f8e7
Compare
058f8e7
to
0ce8a2b
Compare
@@ -0,0 +1,78 @@ | |||
'use client'; |
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.
Do we need this component? Can we use the Link
coming from navigation inside of our custom Link
component?
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.
Yeah, it's what I've thought before. Just didn't want to add changes before we agree on that. I'Il do it now.
|
||
const t = await getTranslations({ locale, namespace: 'Brand' }); | ||
const tPagination = await getTranslations({ locale, namespace: 'Pagination' }); | ||
const dictionary = await getMessages({ locale }); |
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.
Why do we call this dictionary
and not messages
?
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.
We've called core/dictionaries
on top level at the first place. So I've thought that it's aligned more with it. But we can rename it as core/messages
and also change pattern with getMessages
through the project. What do you say?
500cf9e
to
9003e8b
Compare
9003e8b
to
513a911
Compare
513a911
to
a991549
Compare
a991549
to
8e4612d
Compare
8e4612d
to
ebb48c7
Compare
ebb48c7
to
25e03aa
Compare
25e03aa
to
9e804f3
Compare
ce62632
to
455b856
Compare
Co-authored-by: Volodymyr Krasnoshapka <[email protected]> Co-authored-by: Yurii Zusik <[email protected]>
455b856
to
d7e13c6
Compare
⚡️🏠 Lighthouse reportWe ran Lighthouse against the changes and produced this report. Here's the summary:
Lighthouse ran against https://catalyst-latest-o59w2mst6-bigcommerce-platform.vercel.app/ |
What/Why?
This PR adds i18n mechanism to Catalyst. It's basically just a mechanism and will be expanded to all Pages & Components in upcoming PRs.
Ticket
CATALYST-266
Testing
locally
i18n.mov