-
Notifications
You must be signed in to change notification settings - Fork 9
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
Custom slot name braces #15
Custom slot name braces #15
Conversation
@kkuegler, PTAL |
<i18n> | ||
{ | ||
"en": { | ||
"message": "Open the <slot>faq-link</slot> page." |
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.
cool... similar to react-i18next named tags => https://react.i18next.com/latest/trans-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.
Nice, thanks for the contribution!
I added a few nitpicks here and there :)
index.ts
Outdated
@@ -5,6 +5,10 @@ declare module 'vue' { | |||
interface ComponentCustomProperties { | |||
$t: TFunction; | |||
$i18next: i18n; | |||
// Optional custom pattern for matching slot start of the `TranslationComponent. Internal. |
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.
To me it seems better to not have these internal properties be part of the public ComponentCustomProperties
type, as I can't think of a use-case for them in user components, We can just use the internal propertie(s) without declaring them.
…om public API. Address performance issue. Simplify `slotNamePattern()`
@kkuegler, PTAL again. |
Looks good. Thanks again for your PR! |
In this PR I introduce the possibility to provide custom start and end braces (or other string values) used to recognize the end and start of a slot of the
TranslationComponent
.This may be useful when default braces (
{
and}
) are wrongly treated by the Locize service or don't satisfy other needs. In our case, the Locize treated single braces as "wrong" double braces, so we couldn't sync our localization terms with the Locize service without additional refactoring. This service is needed for our translators to edit localization terms and see how it looks in real time. We have to do double refactoring each time before sync. To avoid it, I propose a little change in this repo.Checklist
npm run test
Checklist (for documentation change)