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
It would be a lot nicer to define translated props directly in the translations, without creating separate translation keys.
Example:
translations={"foo": "Translation with react <elem translatedProp="translatedproperty">and translated nested children!</elem>"}functionrender(){return<Localizedid="foo"><MyComponentkey="elem"propViaCode={true}/></Localized>}
Open Questions:
how should the matching happen? using the nodeName matching a react key?
what should happen to elements defined in the translations but not in react children? For example for things like <em> or <strong>
what should happen to elements defined in the react children but not in the translations? Translations are free to use and re-order any of the elements defined in react. Should they also be able to not use an element?
how can we make this lightweight without basically re-implementing the whole virtual dom?
at some point, we would like to separate generating react-specific code and non-react code, how will this interact?
I would have to implement all the html element parsing and make sure the markup is valid, which will be a huge pain…
I created https://github.com/Swatinem/rendez to merge arbitrary react subtrees. Next steps would be to correctly parse html tags inside of translation strings and transform them to react elements to pass over to rendez.
One thing that fluent supports are DOM Overlays, which I would really love to use for multiple reasons:
<Localized />
Component with usage of the rawintl
object via the contextReactNode
.It would be a lot nicer to define translated props directly in the translations, without creating separate translation keys.
Example:
Open Questions:
nodeName
matching a reactkey
?<em>
or<strong>
References:
Fluent DOM Overlays
The text was updated successfully, but these errors were encountered: