Skip to content

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

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

pento
Copy link
Member

@pento pento commented Jun 5, 2025

✨ 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:

// "some.translation.key" = "Welcome, %{username}! The date is %{shortdate}!"
<Translation
  @scope="some.translation.key"
  @options={{hash shortdate=shortDate}}
>
  <:placeholders as |Placeholder|>
    <Placeholder @name="username">
      <UserLink @user={{user}}>{{user.username}}</UserLink>
    </Placeholder>
  </:placeholders>
</Translation>

📺 Screenshots

image

👑 Testing

Review the new integration tests, consider any missing cases that should be covered.

@pento pento self-assigned this Jun 5, 2025
@pento pento marked this pull request as ready for review June 11, 2025 04:59
Comment on lines 171 to 173
element.innerText = `[missing ${this._placeholderAppearance.get(
name
)} placeholder]`;
Copy link
Member Author

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).

@github-actions github-actions bot added the i18n PRs which update English locale files or i18n related code label Jun 11, 2025
Copy link
Contributor

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?

Copy link
Member Author

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. 🙂

Comment on lines +26 to +27
mixed_placeholders:
"Welcome %{username}! You have %{count} messages.",
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
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.

Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n PRs which update English locale files or i18n related code
Development

Successfully merging this pull request may close these issues.

2 participants