feat: Default translation values #86
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/amann/next-intl/52DRkv9ncDnYUVNock6ANqdtmGrw |
|
BTW is one of use-intl's tests broken due to a spelling mistake (plural and singular), I can also create a PR to fix it if you like. |
| @@ -39,6 +40,9 @@ type Props = { | |||
| * afterwards the current date will be returned continuously. | |||
| */ | |||
| now?: Date; | |||
| /** Global rich text elements for consistent styling or usage of rich text tags. | |||
| * Will be overidden by locally provided elements. */ | |||
| defaultRichTextElements?: RichTranslationValues; | |||
There was a problem hiding this comment.
At first I thought we might need to restrict this to only accept functions and no TranslationValue to avoid abusing the config option. But now I'm wondering if we should expand this to defaultTranslationValues?: RichTranslationValues.
I mean the primary use case is definitely to supply rich text elements, but this could be convenient to provide some common values that are often used. You can use state management solutions for this, but maybe it could come in handy for data that is only used in messages.
What's your opinion here? I tend to go for defaultTranslationValues to give the user more capabilities since we're already adding this feature.
There was a problem hiding this comment.
Actually I had the same thought the day after the PR. I am also in favour of this solution and not just the rich text elements :)
| <App /> | ||
| </NextIntlProvider> | ||
| ``` | ||
|
|
There was a problem hiding this comment.
BTW is one of use-intl's tests broken due to a spelling mistake (plural and singular), I can also create a PR to fix it if you like.
Which is the test you're seeing problems with? Seems like CI passes. I'd be curious if it's a problem related to the environment. You might need node>=14, this is currently not enforced.
There was a problem hiding this comment.
use-intl/test/useIntl.test.tsx:274:29
It's simply a spelling mistake, the expected value is "Invalid currency codes" (plural) where as the recieved value is "Invalid currency code" (singular).
There was a problem hiding this comment.
I think if you run git revert 34d9c05 in your branch that should do the trick.
maxwoedl
changed the title
| @@ -272,7 +272,7 @@ describe('formatNumber', () => { | |||
|
|
|||
| const error: IntlError = onError.mock.calls[0][0]; | |||
| expect(error.message).toBe( | |||
| 'FORMATTING_ERROR: Invalid currency codes : unknown' | |||
| 'FORMATTING_ERROR: Invalid currency code : unknown' | |||
There was a problem hiding this comment.
Hmm, locally this is indeed "codes" for me with node v14.19.0. Seems like on CI there's the same result. Which node version are you using where you're seeing "code"?
There was a problem hiding this comment.
I am using node v16.13.1, so you were correct about the node version, sorry for "fixing" the test, i will undo it :)
There was a problem hiding this comment.
No problem! An upgrade to node v16 would definitely be interesting, but I'm not sure yet if there are other CI-related things to update then so that can be done at a later point for sure.
| @@ -149,6 +149,7 @@ t('selectordinal', {year: 11}); | |||
| ## Rich text | |||
|
|
|||
| You can format rich text with custom tags and map them to React components. | |||
| If you want to use the same tag multiple times, you can configure it via the [default translation values](/docs/usage/configuration#default-translation-values). | |||
There was a problem hiding this comment.
Nit: Can we move this after the code snippet? I feel like it could be helpful to first finish introducing the concept and then providing supplemental information like the global config. It might also help a bit with discovery, I tend to skip directly to the code examples when reading a section and expect advanced information to follow afterwards.
To achieve consistent usage and styling of rich text elements, I have included an option to define global defaults for rich text elements. The default will be overridden by a local definition of an element.
This approach is the same as the one from react-intl.