Previously, I had implemented the hint text ("Search)" and image (the magnifying glass)
as a custom text box definition. This caused some problems, though. Since the string was
hard-coded as part of a WFL formula, it couldn't be translated (see #2709 and #2732). It
also wasn't expandable to any other usecase.
Instead, I've added two new hint_text= and hint_image= keys to [text_box], wrapped the
"Search" text and magnifying image path in a helper macro, and refactored the default
definition to display the hint text and image when appropriate.
This also fixes a minor issue where selected text wouldn't remain highlighted when the
box wasn't focused when using the filter definition (it did with the default one).
This should fix the untranslatable "Search" text issue mentioned in both issues above.
The new string is in the wesnoth-lib textdomain.
Resolves#2748.
Essentially, all this did was tell users to go use the forum, so it wasn't worth
it to keep it and solve the infinite loading screen issues it was causing.
The server backend still needs to be cleaned up.
Also removed a dead reference to some "Change Username" button in the Login dialog's
code.
in linger mode.
playmp_controller::play_linger_turn calls play_slice after processing
end_linger/[notify_next_scenario] which would (after 'fix chat in
[delay]' commit) then read more data from the network in particular data
for the next scenario which will then be lost.
with the 'fix chat not working during delay/animation' it could happen
that play_slice_catch would process a incoming controller change in
which case that while loop would end without the code inside that 'if
(player_type_changed_)' being executed, which woudl lead to oos errors
since that client woudl have made moves that other players don't have.
These were never intended to go in that commit at all. I accidentally included them.
This reverts the semantic changes. The rest was just formatting so I'm leaving it.
The Boost unit tests have been failing since I removed the GUI2 event context since the
code expects both that A: the topmost context is the global one and B: that you can't
use join() to join the global context. Removing the UI event context meant the test's
fake_display event_context became the only (and global) context, causing an assert.
Textures can't be created with faked video. That's pretty much the only
reason why creating that texture can ever fail (other cases, such as
credits, stress the text rendering system much more than floating labels).
This replaces the use of the boost::mpl::set lists. It replaces those damn things with simple
constexpr functions that check the template parameter against an accepted list for each event
type. This is a *lot* simpler.
These helpers are also used in the runtime checks in dispatcher::fire.
I've had to leave the mpl sets in, though, since I can't figure out how to convert the last
place where they're used. The presence of a type is required for SFINAE in
dispatcher_implementation::event_signal, and I can't figure out a new design that avoids the
need for the template parameters.
This function only ever had an implementation when building the i18n API
to use libintl instead of Boost.Locale was possible, in which case its
implementation would be a std::setlocale() call specific to POSIX
systems.
I'm not backporting this to 1.14 since it's an inconsequential cosmetic
thing, or so I'd like to think. Last time someone tried to remove a
similarly empty "init" function elsewhere, things went south pretty
quickly.
This drops a preprocessor conditional branch that is dead code now that
the file pulls gettext.hpp and the GETTEXT_DOMAIN defaults with it.
See also PR #2711.
There are cases (deprecation.cpp for one) where string_utils.hpp is
included first, which causes the VGETTEXT/VNGETTEXT definition to use
the textdomain-less (a.k.a. forced wesnoth-lib textdomain) overloads of
vgettext() and vngettext(), because GETTEXT_DOMAIN has not yet been
defined by anything. This again results in strings being looked up in
catalogues where xgettext is not adding them.
This is a companion for PR #2711 I should've noticed sooner. Without it,
there were still cases where interpolated strings would not be
translated due to vgettext() using the wrong textdomain for them.
I ran a quick scan on the codebase to make sure there aren't any files
including formula/string_utils.hpp before defining their own
GETTEXT_DOMAIN instead of the gettext.hpp default.
The vgettext() function, while declared in src/formula/string_utils.hpp,
actually has its implementation out-of-line in
src/formula/string_utils.cpp where GETTEXT_TEXTDOMAIN is defined to
"wesnoth-lib". Because vgettext() is implemented in terms of the _()
function (an inline wrapper around translation::dsgettext()), it passes
the textdomain defined in the file where it was implemented as a
parameter.
This means that every case of vgettext() being used in other code units
where GETTEXT_TEXTDOMAIN is not defined to "wesnoth-lib", is broken if
the string being looked upon doesn't coincidentally exist in the
wesnoth-lib textdomain.
Ages ago, to work around this limitation, an overload of vgettext() that
takes the textdomain name as a parameter was introduced (see commit
0ba3d05204). Since this form of vgettext()
is rather unwieldy to use (and in particular, the xgettext message
extraction tool mistakes the first argument for the msgid, see below), a
VGETTEXT() macro was also added that uses the GETTEXT_TEXTDOMAIN symbol
defined in the file where the call is made, and thus we get the correct
string from the correct textdomain.
Switching all cases of naked vgettext() in mainline to VGETTEXT() fixes
a myriad of situations where an interpolated string that has an extant
translation does not actually get translated in practice because of the
mismatched textdomain reference (see issue #2709 for an example with MP
game titles). I couldn't find any cases of the companion vngettext()
function (which handles plurals) being used in the wild naked, but for
future reference it also has a companion VNGETTEXT() macro to pass the
correct textdomain to its textdomain-parameter overload.
One caveat is that this commit DOES break the string freeze in one
particular case -- src/units/unit.cpp has a case where the
textdomain-parameter version of naked vgettext() was in use with
"wesnoth" as the first parameter, and xgettext misidentified this as a
translation entry for a "wesnoth" string in the file's assigned
textdomain (which is the default textdomain, wesnoth). So this will
result in the next pot-update both removing the spurious "wesnoth"
string AND adding the correct string to the relevant catalogue template
("<span color=\"$color\">$number_or_percent</span> HP").
to that textdomain.
Other than that, I believe this does not break the string freeze in any
other fashion and it shouldn't result in any regressions for i18n.
It might be worth considering in the future renaming vgettext() and
vngettext() to names that make people less likely to misidentify them as
functions they can freely call directly without regard to the textdomain
assignment issue.
