[ci skip]
Source: https://dejavu-fonts.github.io/Download.html
I haven't done any codepoint list updates in data/hardwired/fonts.cfg, but that's
not relevant anymore since it's for the legacy TTF rendering system which is in
the process of being removed.
(cherry-picked from commit 11e88dd1caf22af0d65a1785ff8e972f6a99270d)
[ci skip]
Source: http://arkandis.tuxfamily.org/adffonts.html. Previous version was 1.006 (FFEdit).
Also includes the italic and bold variants we didn't have before.
Thanks to @sevu for finding this updated version. :)
(cherry-picked from commit cef0edb4ac02e9cbb3c7044466f9655a1e66278f)
This is the current default, and even though the job uses scons this also sets the osx version to use. Therefore it's better to set it explicitly in case the default changes at some point.
(cherry-picked from commit 376f2e9dbe562c21671f88e8f3ef932b003a7fb5)
[ci skip]
I misread the intent of that line in the original. It was supposed to clear the
var, not set it.
(cherry-picked from commit bad574f7c8f6106e6879c14318f3fcf0ec4cc2bf)
since it was removed in 10561d3e539e6c92aa99d164bbe5bb106c7f35fd this will cause errors. Please make sure it is not used in mainline before you remove something.
(cherry-picked from commit 83007d4825c0a9daca158ec821da34c8968b7536)
This is since the Gamestate Inspector can be invoked mid-event (using [inspect])
and it makes use of write_events().
(cherry-picked from commit afaa75842c8914406bed75d3557ec241b0de9b6a)
In particular, this enables C4100, the warning for unreferenced function
parameters.
I also fixed some /W4 warnings.
(cherry-picked from commit d4c9db9e3529434bf29a4ed237bc64e67f868f45)
This reverts commit cdf9b465c668648721c4638ce117da130ad36284.
May this noise be my vengeance.
(cherry-picked from commit f6a128579ad6d94cc7c8a57bebd1fc2bb0f735a0)
utils/travis/install_deps.sh - no longer executes anything outside of the osx if block.
utils/travis/exit_wrapper.sh - I honestly don't know why this exists.
utils/travis/test_wrapper.sh - No longer used as of 7ca5a0df6449b4b895842566d33a38872f1f507e.
(cherry-picked from commit 344b5c56b90cffcbc9638bcb7535bb3e0f073da7)
Since these are defined in their MAKE_ENUM enum with N_, we need to manually un-not-translate
them here.
(cherry-picked from commit 2e502334f23447609e2553cbbbae8b251f9796bc)
This removes the -g option from the xcode travis build, since debugging information isn't needed and the increased size was causing the cache to timeout when compressing and uploading it. ccache max cache size is also decreased from 2 GBs to 200 MBs, which matches the linux+cmake builds. Fixes#2670.
(cherry-picked from commit b801140344c7cbf86980ff54ef963f9ec2122897)
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.
(cherry-picked from commit 94c5f64cc62452f420a9886eefc75d5e4af121fc)
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.
(cherry-picked from commit a60239116863ea7592d27f2819017b57a34e0ce5)
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.
(cherry-picked from commit 5c28dcaab66e34af718c7ceff6ccc9e33b58b039)
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
0ba3d05204abff72f7d95cf11a91536dab5aa20a). 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.
(cherry-picked from commit c5b3947e4a837dc98868e3b2c3fa55668fec27a4)
He was changed to female in f4d67031a436 even though he's addressed as "brother" in dialogue. Reported on the forums.
(cherry-picked from commit 3be2ff518781c7a7104e810707be64567cc26e27)
