-
Notifications
You must be signed in to change notification settings - Fork 8.6k
DEV: Add a Translation component. #33082
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: main
Are you sure you want to change the base?
Conversation
element.innerText = `[missing ${this._placeholderAppearance.get( | ||
name | ||
)} placeholder]`; |
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.
Writing directly to the DOM isn't ideal, but this should only be occurring if there's a placeholder missing (ie, in development/testing environments).
app/assets/javascripts/discourse/app/components/translation.gjs
Outdated
Show resolved
Hide resolved
app/assets/javascripts/discourse/app/components/translation.gjs
Outdated
Show resolved
Hide resolved
app/assets/javascripts/discourse/tests/integration/components/translation-test.gjs
Outdated
Show resolved
Hide resolved
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 wondering if we should consider the case where a placeholder component is used but the key does not match any existing placeholders. Maybe we should raise an error in the dev/test env to help catch mistakes early?
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 to add the complexity of tracking placeholder components that are defined by not rendered? It'd be roughly the same as adding another TranslationPlaceholder.markAsRendered()
codepath. Given that we don't do this in i18n()
, I'm inclined not to. Open to arguments in favour, though. 🙂
mixed_placeholders: | ||
"Welcome %{username}! You have %{count} 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.
mixed_placeholders: | |
"Welcome %{username}! You have %{count} messages.", | |
mixed_placeholders: | |
"Welcome %{username}! You have %{count} messages.", | |
repeated_placeholders: | |
"Welcome %{username}! Hello %{username}! |
Repeated placeholders seem like a worthwhile case to test as well.
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 definitely won't work, unless there's a nice way to duplicate components, since we'd need to render two copies of the same placeholder component into different target elements.
✨ What's This?
Reference: t/155601
A new
<Translation>
component for interpolating components into translatable strings.This PR also includes a little bit of refactoring in the
i18n
library to make it easier to hook into.Example:
📺 Screenshots
👑 Testing
Review the new integration tests, consider any missing cases that should be covered.