Skip to content

Conversation

@lanurmi
Copy link
Owner

@lanurmi lanurmi commented Nov 14, 2024

No description provided.

@lanurmi lanurmi force-pushed the gettext-literal branch 2 times, most recently from 9973ed3 to c6d123b Compare November 15, 2024 13:44
Point translation macros to wrapper functions that only accept
string literals. This is a backward-incompatible change,
though most incompatibilities found are likely to be bugs.

While at present the arguments do not technically need to be string
literals, variables can easily introduce subtle bugs that are not
obvious to spot. The fact that xgettext only picks string literals
is easy to forget.

Consider  the following code:
wxString itm("item");
_(itm);
wxGETTEXT_IN_CONTEXT("context_1", itm);
wxGETTEXT_IN_CONTEXT(itm, "item");
wxPLURAL(wxString::Format("%s", "singX"), "plurX", 1);
wxPLURAL("singY", wxString::Format("%s", "plurY"), 2);
wxGETTEXT_IN_CONTEXT_PLURAL("context_1", _("singZ"), "plurZ", 1);

All of these lines compile without warnings. However, only one string,
"singZ", is picked by xgettext, all others are silently ignored. Some
lines would work if accompanied by a proper wxTRANSLATE* call, but nested
calls (see the last line) to translation macros do not make sense in the
first place.
While this is technically a change in 3.3.0, the macros always required
string literal arguments in practice, although it was not enforced.
Defining wxNO_REQUIRE_LITERAL_MSGIDS enables the old behaviour, where
translation macros do accept variables as string arguments.

The arguments nearly always need to be string literals, though, and
before defining this macro, it is advisable to check whether the code
should be fixed instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants