Create a mock for gettext-rs in order to fix the failing build on macos #181
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A temporary fix for failing build on macos https://github.com/rustcoreutils/posixutils-rs/actions/runs/10173778299/job/28138428272 which is highly likely to be related to gettext-rs/gettext-rs#121
A long term resolution will likely involve one of the following:
a) Wait for gettext-rs/gettext-rs#119 to get merged, and then fix the breaking changes introduced by dennisschagt/gettext-rs@ec1aad1
b) Use https://docs.rs/gettext/0.4.0/gettext/ instead accepting its limitations and it's apparent abandonment.
c) Fork
gettext-rs
.d) Replace gettext entirely with a more modern localization system. https://github.com/unicode-org/message-format-wg is still in the works, and so something based on https://github.com/projectfluent/fluent-rs seems likely to be the best option. My biased opinion (maintainer of the project) is that https://docs.rs/i18n-embed/latest/i18n_embed/ along with https://docs.rs/i18n-embed-fl/latest/i18n_embed_fl/macro.fl.html could be a good option for doing this in an established pattern, and would be willing to put in the time to pare down any dependencies and add any small features necessary to make it work for this project.
e) Roll our own very limited localization system to keep dependencies to a minimum. If accessibility really is a priority I don't see this being a great option, it also makes external tooling around localization more limited.