-
Notifications
You must be signed in to change notification settings - Fork 193
bugfix(web-runtime): [OCISDEV-267] fix progress bar not being translated when user changes language #13108
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
Conversation
|
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
…ted when user changes language
a43c01f to
f4ce0dc
Compare
|
LukasHirt
left a comment
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.
So I take it using composable for the extension was not enough? I fear this is not the right approach though.
- This fix would most probably apply only to this specific progress bar but wouldn't affect other ones.
- I think re-registering the extension point will break the system (see specific comments on the LOC).
| description: $gettext('Customize your progress bar') | ||
| } | ||
| } | ||
| extensionRegistry.registerExtensionPoints(toRef([progressBarExtensionPoint])) |
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.
I'm quite worried what re-registering extension point will do. If there are any other progress bar extensions, are they persisted or are they lost due to this?
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.
good points. I have to check..I'm not sure. Do you have any other ideas in general? I couldn't come up with anything better. 🙈
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.
If the computed prop did not work, I have no other idea from top of my head. I would need to dig deeper.
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.
If the computed prop did not work, I have no other idea from top of my head. I would need to dig deeper.
Nope, it didn't work either. Already tried that. I will try to find something else and we can talk tomorrow. 👍🏻
| const progressBarExtensionPoint = ref(registerProgressBarExtension()) | ||
| watch( | ||
| () => $gettext('Global progress bar'), |
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.
If it's needed to depend on the locale, wouldn't it be nicer to use current from the useGettext composable?
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.
current is just a string, so it doesn't trigger reactivity when it changes. I thought the same, but didn't work, unfortunately. :(
| () => $gettext('Global progress bar'), | ||
| () => { | ||
| extensionRegistry.unregisterExtensions([progressBarExtensionId]) | ||
| extensionRegistry.unregisterExtensionPoints([progressBarExtensionPoint.value.id]) |
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.
Same worry as in the register function... I do not think other progress bars will survive this.
|
Fixed in #13126 |
|
Closing as the other PR has been merged. |



Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Open tasks: