AddCatalog doesn't fail with wxLANGUAGE_DEFAULT #18227
Comments
2018-09-23 01:32:31: @vadz commentedI'm not sure what should we be doing here as having Vaclav, would you have any thoughts about this? |
2018-11-18 01:47:58: @vadz changed status from new to closed2018-11-18 01:47:58: @vadz set resolution to fixed2018-11-18 01:47:58: @vadz commentedIn 2d784da: This way the first and only fallback language isn't necessarily the As a side effect, fixes #18227 in one possible way. |
2018-12-17 02:28:12: slodki commented
Above statement is not true - AddCatalog used to fail when a catalog in the default language was not found AND separate message catalog file was required (default language <> msgIdLanguage): https://github.com/wxWidgets/wxWidgets/blob/v2.8.12/src/common/intl.cpp#L2830 Now in 3.1.2 it fails if the most preferred language is the source code language - we leave loop with See #18297 |
2018-12-18 05:33:31: @vadz commentedI feel that perhaps we should revert 2d784da (as well as the recent fixes for the regressions introduced by it), finally, as in addition to the already fixed #18297 and #18299 we still have #18300 (not sure if everything there will be fixed by reverting though) and #18302 (which will be, I think). I still have no idea how to fix the original problem, however. But it's arguably less bad than all the problems that were caused by fixing it. |
2018-12-18 23:32:41: @lanurmi commentedReplying to [comment:3 slodki]:
Fair enough, it is not true in the strictly logical sense, but it is true as a statement expressed in everyday English. Replying to [comment:4 vadz]:
I agree that at this point it seems reasonable to revert the change, as it turned out to be more complex to handle all use cases correctly than it seemed at first. Further work is needed apparently. It was unfortunate to introduce such problems to an actual release, but on the other hand I wonder if we would have received all the feedback if the change were only present in unreleased master. #18300 seems partially unrelated to this very change. |
2018-12-23 17:34:06: @vadz commentedIn 270ad54: The latest changes to wxTranslations::AddCatalog() behaviour were not This is a combination of the following commits: Revert "Fix regression in wxTranslations::AddCatalog()" This reverts commit 14e9058. See #18297. Revert "Fix crash in translations code when no translations are found" This reverts commit 80904d1. See #18299. Revert "Rename new wxTranslations method to GetAcceptableTranslations()" This reverts commit 20b02d6. Revert "Load catalogs for all preferred languages, if they exist" This reverts commit 2d784da. Revert "Allow getting all usable translations languages" This reverts commit 5d08e40. Closes #18302. |
The new function only returns true if the catalog could be really loaded and not if it is considered not to be needed because the message ID language (which is typically "en-US") happens to be present in the preferred UI languages list (which seems to always include "en-US" in at least Western European MSW). This allows to ditinguish, albeit in a rather awkward (but backwards-compatible) way between having a translation for the given language and not needed such translation. It is still not clear if it is really correct to return "en-US" from the list of preferred languages even if the user has never intentionally configured the OS to indicate that English is acceptable, but at least now we can work around this issue and use AddAvailableCatalog() in AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo if the versioned wxstd-x.y.mo file is really found instead of never doing it, as was the case until now (see wxWidgets#23886). Also add GetBestAvailableTranslation() helper which seems more useful than the existing GetBestTranslation() one and is similarly related to it. See wxWidgets#18227.
|
After returning to this, I realize that I actually have a problem with adding Unfortunately to solve this we'd need to change For the record, I've toyed with the idea of returning false from So I've created #23918 which is supposed to address this. Please let me know what do you think! |
Would it feel OK to you if the function was called GetBestUILanguage() instead? That is, I think, the rationale behind that behavior: it is meant to return the language available for use, which is usually "translation", but not in the msgid/English case. But omitting msgIdLanguage from the list would require special-casing that one language everywhere. |
|
I agree that calling it But mostly, renaming it is still not going to solve the problem of |
The new function only returns true if the catalog could be really loaded and not if it is considered not to be needed because the message ID language (which is typically "en-US") happens to be present in the preferred UI languages list (which seems to always include "en-US" in at least Western European MSW). This allows to distinguish, albeit in a rather awkward (but backwards-compatible) way between having a translation for the given language and not needed such translation. It is still not clear if it is really correct to return "en-US" from the list of preferred languages even if the user has never intentionally configured the OS to indicate that English is acceptable, but at least now we can work around this issue and use AddAvailableCatalog() in AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo if the versioned wxstd-x.y.mo file is really found instead of never doing it, as was the case until now (see #23886). Also add GetBestAvailableTranslation() helper which seems more useful than the existing GetBestTranslation() one and is similarly related to it. See #18227.
The new function only returns true if the catalog could be really loaded and not if it is considered not to be needed because the message ID language (which is typically "en-US") happens to be present in the preferred UI languages list (which seems to always include "en-US" in at least Western European MSW). This allows to distinguish, albeit in a rather awkward (but backwards-compatible) way between having a translation for the given language and not needed such translation. It is still not clear if it is really correct to return "en-US" from the list of preferred languages even if the user has never intentionally configured the OS to indicate that English is acceptable, but at least now we can work around this issue and use AddAvailableCatalog() in AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo if the versioned wxstd-x.y.mo file is really found instead of never doing it, as was the case until now (see wxWidgets#23886). Also add GetBestAvailableTranslation() helper which seems more useful than the existing GetBestTranslation() one and is similarly related to it. See wxWidgets#18227, wxWidgets#23930. (cherry picked from commit 94b1a17)
The new function only returns true if the catalog could be really loaded and not if it is considered not to be needed because the message ID language (which is typically "en-US") happens to be present in the preferred UI languages list (which seems to always include "en-US" in at least Western European MSW). This allows to distinguish, albeit in a rather awkward (but backwards-compatible) way between having a translation for the given language and not needed such translation. It is still not clear if it is really correct to return "en-US" from the list of preferred languages even if the user has never intentionally configured the OS to indicate that English is acceptable, but at least now we can work around this issue and use AddAvailableCatalog() in AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo if the versioned wxstd-x.y.mo file is really found instead of never doing it, as was the case until now (see wxWidgets#23886). Also add GetBestAvailableTranslation() helper which seems more useful than the existing GetBestTranslation() one and is similarly related to it. See wxWidgets#18227, wxWidgets#23930. (cherry picked from commit 94b1a17)
The new function only returns true if the catalog could be really loaded and not if it is considered not to be needed because the message ID language (which is typically "en-US") happens to be present in the preferred UI languages list (which seems to always include "en-US" in at least Western European MSW). This allows to distinguish, albeit in a rather awkward (but backwards-compatible) way between having a translation for the given language and not needed such translation. It is still not clear if it is really correct to return "en-US" from the list of preferred languages even if the user has never intentionally configured the OS to indicate that English is acceptable, but at least now we can work around this issue and use AddAvailableCatalog() in AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo if the versioned wxstd-x.y.mo file is really found instead of never doing it, as was the case until now (see wxWidgets#23886). Also add GetBestAvailableTranslation() helper which seems more useful than the existing GetBestTranslation() one and is similarly related to it. See wxWidgets#18227, wxWidgets#23930. (cherry picked from commit 94b1a17)
When the original messages language matches the language of the locale being used, these strings can be used directly and so AddCatalog() should still return true for them but it didn't do it any more after the changes of 94b1a17 (Add AddAvailableCatalog() and use it in AddStdCatalog(), 2023-09-30). See wxWidgets#18227. Closes wxWidgets#24019.
When the original messages language matches the language of the locale being used, these strings can be used directly and so AddCatalog() should still return true for them but it didn't do it any more after the changes of 94b1a17 (Add AddAvailableCatalog() and use it in AddStdCatalog(), 2023-09-30). See #18227. Closes #24019. Closes #24037.
When the original messages language matches the language of the locale being used, these strings can be used directly and so AddCatalog() should still return true for them but it didn't do it any more after the changes of 94b1a17 (Add AddAvailableCatalog() and use it in AddStdCatalog(), 2023-09-30). See #18227. Closes #24019. Closes #24037. (cherry picked from commit 39079cb)
Issue migrated from trac ticket # 18227
component: wxMSW | priority: normal | keywords: addcatalog translations locale
2018-09-22 17:47:19: @lanurmi created the issue
When
wxLocaleis inited withwxLANGUAGE_DEFAULT, and the default language is non-English,wxTranslations::AddCatalogreturnstrueeven if the requested catalog in the preferred language was not found. This is specific to Windows, possibly also Mac, but *nix is not affected.What happens is that on non-English Windows (for example, Windows 7 in Finnish), GetPreferredUILanguage returns two languages:
fi_FIanden_US. Now, if the catalog for Finnish was not found, the original msgid language English is still considered to satisfy what the caller asked for, so no error is returned. This is however not what the caller expected, and on *nix an error would be returned.I also tested this on a Windows 10 installed in German, and again two preferred languages are returned. On neither machine has the user (me) done anything to choose English as a secondary language.
In wx 2.8
AddCatalogused to fail when a catalog in the default language was not found. On *nix it still does.Steps to reproduce in the unmodified internat sample:
0. Have something else than English as the preferred language.
The text was updated successfully, but these errors were encountered: