On Tue, 8 Aug 2023 11:31:33 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>> Changing locale mid-application isn't something that seems like a good idea. >> Is that really what they want - not sure the test is exactly about that. >> Really I'm quite unclear as to whether the complaint is that some custom >> resource bundle isn't being used, or that there appears to be no FR >> localisation, or what ? >> >> And if a Alexey says the change is renaming an internal action command >> string that seems odd. >> >> I think this needs a better understanding to start with of what localisation >> support we have, and how it is being incorporated into the build and whether >> its being done as intended. >> >> After that is sorted we can ask for clarification as to what they really >> want to do. >> I'm not sure this change will even help them, right or wrong. > >> Yeah @prrace , you are right. According to the bug, they want to change the >> locale mid-application. Meaning switching between locale mid-application, >> which seems to be wrong/not something to be done with existing flow. I >> understood it wrongly and hence the fix also is wrong. The locale is set and >> updated on application startup ( >> [here](https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java#L841) >> ). Hence I will close this PR. > > It's not an invalid scenario, perhaps we could improve the support for this > scenario. Yet we still need to understand better what was the original goal > so that we could propose a solution. > > https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java#L841-L844 > > If the fields `newFolderString` and `newFolderNextString` aren't constants > but are fetched from `UIManager` whenever they're used, locale can be > changed. The same holds for other instances of localisable resources. At this > time, changing UI language isn't supported, at least for `JFileChooser`. > > Some apps require restart to change the UI language, some apps support such a > change on the fly. > > Some apps update their formatting options right after the user modifies the > format settings in the OS, some apps still require a restart. > > Then another solution could be extending the resource bundle to provide > translations for languages that aren't available in JDK. True. So it does require some re-thinking on how to move ahead on this issue. As per my understanding, user wants to change locale at run-time (Application Runtime, not necessarily JFileChooser component) where first use English locale to create JFileChooser perform some operations (Or not) and close it, open up another JFileChooser with French Locale. The observation is that only `New Folder` locale remained in English while other component text changed. This is due to Single WindowsFileSystem object used through the application time and fields `newFolderString` and `newFolderNextString` are fetched at object creation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15069#discussion_r1287952141
