Qute i18n: attempt to resolve ambiguity for multiple localized files #50829
Conversation
mkouba
commented
Nov 4, 2025
mkouba
commented
- resolves Allow to define Qute i18n default values as properties #47585
|
@ia3andy Could pls test this PR with the roq use case you talked about? |
This comment has been minimized.
This comment has been minimized.
|
Thanks @mkouba :) I 'll have a look! |
This comment has been minimized.
This comment has been minimized.
Status for workflow
|
|
🙈 The PR is closed and the preview is expired. |
| Localized files from the application root have higher priority and take precedence over localized files from dependencies. | ||
| If multiple files of the same priority exist, then the build fails. | ||
| For example, if the default bundle locale is `en` and the files `msg.properties` and `msg_en.properties` are found in the application root, then an exception is thrown and the build fails. | ||
| Or another example - if there are two dependencies and both contain the `msg_en.properties` file, then the build fails again. |
There was a problem hiding this comment.
But it is quite natural that there will be 2 dependencies with msg_en.properties, each with localized messages for their own messages. They do not need to overlap, unless they define the same localizations. Wouldn't it be smarter to merge them and only fail build if there are any conflicts in defined messages (like they define the same localization and with different value)?
There was a problem hiding this comment.
Maybe I am just missing something?
There was a problem hiding this comment.
So I don't think it's very common. You still need a message bundle interface. The main use case is Roq which provides a message bundle interface + default message files (dependency) but the user can override messages in localized files in the app (application root).
Wouldn't it be smarter to merge them and only fail build if there are any conflicts in defined messages (like they define the same localization and with different value)?
It would be smarter but also even more complex to implement and more difficult to understand, i.e. sometimes the message can be overriden, but sometimes it's a conflict 🤷.
There was a problem hiding this comment.
Ok, let's go with your version and wait for possible user change request.
There was a problem hiding this comment.
For sure, we can always make it smarted later 😉.
Status for workflow
|
|
I am currently trying it, I had a few issue build issues (as you saw on zulip) |
|
Awesommmme it works like a charm!!! |
3 participants
