Conversation
💔 Build Failed |
Yes, we're changing this for legacy plugins here: #26078, so no worries :) But i18n support in new platform is still in flux, if i18n is passed as service via plugin life-cycle hook arguments (as any other services in NP) then one wouldn't be able to just statically import it. We'll throw some ideas later and ask for feedback if it's going to change how we use i18n. I may not be able to review PR earlier than the next week, so adding @Bamieh in case his availability is better than mine this week. CI is failing because of inappropriate localizable label prefix 😉 |
|
@cjcenizal I am a bit worried about this PR as it touches almost all the components with lots of changes for just code style. I would have waited to have the feature completed (full CRUD) before making the code style recommendations. Please don't merge this before my |
💔 Build Failed |
💚 Build Succeeded |
There was a problem hiding this comment.
wouldn't it be better here to use this.setState(prevState => ({...}))?
There was a problem hiding this comment.
Good catch! This is being fixed in a separate PR.
ee6413a to
5424f01
Compare
💔 Build Failed |
|
Retest |
💚 Build Succeeded |
2f721c0 to
236e4f3
Compare
- Add crossClusterReplication and remoteClusters to .i18nrc.json - Replace snake case IDs with camel case. - Export single components. - Pass i18n check. - Rename autofollow to autoFollow. 3
236e4f3 to
743adb8
Compare
💚 Build Succeeded |
@azasypkin Is there any way we can change the way plugin translations are initialized to ensure they're available? If this is at all possible, I think it would be a huge DX win to solve the problem from that angle rather than require consumers change the way they write code to account for this race condition.