You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ℹ️ This is the feature I mentioned in #213 , the idea comes out from the discussions in #211 .
The <i18n> component was designed for use cases of translating strings with html tags (solves #75 , yes, me again 😅 ). The idea consists of two parts and has a prerequisite.
Proposal
To provide an optional place attribute for the child nodes. So that the user can explicitly define which is which.
<div>This is <strong>bold</strong> and <em>italic</em>.</div><div>This is <em>italic</em> and <strong>bold</strong>.</div>
To provide a places attribute for the <i18n> component to define text content.
As discussed in #210 and #211, there's a tricky pitfall in parsing text nodes inside <i18n> - you cannot determined whether an empty text node is user defined by intention, or just some line breaks/indentations. So for use cases of both html tag and plain text are in a message string, I'd like to expand the <i18n> component like this:
messages: {en: {info: 'You can {0} until {1} minutes from departure.',refund: 'refund the ticket',change: 'change your flight'}},data: {limit: {refund: 30,change: 15}}
When places is provided, place attribute for child nodes become mandatory.
The prerequisite
This proposal brings up another issue: currently <i18n> only supports list formatting, and relies on the input order of its child node. So the prerequisite is to make list formatting syntax sugar of named formatting (#213).
The text was updated successfully, but these errors were encountered:
ℹ️ This is the feature I mentioned in #213 , the idea comes out from the discussions in #211 .
The
<i18n>
component was designed for use cases of translating strings with html tags (solves #75 , yes, me again 😅 ). The idea consists of two parts and has a prerequisite.Proposal
place
attribute for the child nodes. So that the user can explicitly define which is which.Renders:
places
attribute for the<i18n>
component to define text content.As discussed in #210 and #211, there's a tricky pitfall in parsing text nodes inside
<i18n>
- you cannot determined whether an empty text node is user defined by intention, or just some line breaks/indentations. So for use cases of both html tag and plain text are in a message string, I'd like to expand the<i18n>
component like this:When
places
is provided,place
attribute for child nodes become mandatory.The prerequisite
This proposal brings up another issue: currently
<i18n>
only supports list formatting, and relies on the input order of its child node. So the prerequisite is to make list formatting syntax sugar of named formatting (#213).The text was updated successfully, but these errors were encountered: