Open Kangie opened 3 weeks ago
msgfmt is now standardized by POSIX 2024: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/msgfmt.html
I suppose that we can assume any of the POSIX documented options shall exist. :) I do not know whether gettext-tiny, which predates 2024, is conformant but they presumably wish to be.
/cc @alanc @awilfox @q66
i removed gettext-tiny over a year ago so i no longer care myself
I'll look more in-depth later, but:
-c
: implemented-D
: intentionally not implemented, will work with upstream-f
: silently ignored, can work with upstream if this is needed-o
: implemented-S
: not caught, will trigger invalid option; will work with upstream-v
: assumed when -c
is given, so I consider that implemented
-f
: silently ignored, can work with upstream if this is needed
I would say so; any projects that have translations marked fuzzy
will have those lines silently excluded from the output if this option is not honoured, resulting in incomplete message object files and a big WTF debugging session.
This sort of translation omission is also unlikely to be picked during testing - we got lucky with fvwm3 that this was caught early.
Describe the bug Currently there is no way to pass an option (e.g.
-f/--use-fuzzy
) tomsgfmt
meaning that we are unable to successfully translate projects that have extant translations (albeit marked fuzzy).While modifying the translation to not be fuzzy is an option, this will increase translator workload and require that existing strings be reviewed.
Instead we should provide a configuration option of some kind that enables this (not uncommon) workflow.
To Reproduce N/A, see:
https://github.com/mesonbuild/meson/blob/d48602a5f3dade3c1800b3e3d11ad09a45a761a2/mesonbuild/modules/i18n.py#L288-L306
Expected behavior Projects should be able to pass appropriate options to
msgfmt
, be this via an explicitly-whitelisted list or directly "at your own risk".E.g.:
or
system parameters N/A