The Highlight Callsign (13) UDP message now operates in a slightly
different way. The "Highlight last" field, when true valued, causes
all instances of the specified callsign to be highlighted in the
decoding period. This allows external applications to highlight DX
callsigns even when multiple stations are calling them. Before this
was unlikely to work since the external application would have to
respond to Decode (2) UDP messages exceedingly quickly to guarantee
successful highlighting before another decode with the same DX call
was printed. There should be no changes required to external
applications acting as servers to the WSJT-X UDP Message Protocol,
although using the version of the Highlight Callsign (13) with
"Highlight last" should not be required for adhoc callsign
highlighting. It should be reserved for commonly recurring targets and
limited to no more than 100 active highlighting requests at any one
time, otherwise there may be performance impacts on WSJT-X.
Load a base language translation file if found. E.g. if locale
language is es-AR then wsjtx_es.qm will be loaded before
wsjtx_es_AR.qm. this allows partial translations for languages where
variants or dialects only require some translated strings to be
different from the base language translations. the aim is to greatly
simplify the work of translators, particularly when doing updates to
translations.
Load a base language translation file if found. E.g. if locale
language is es-AR then wsjtx_es.qm will be loaded before
wsjtx_es_AR.qm. this allows partial translations for languages where
variants or dialects only require some translated strings to be
different from the base language translations. the aim is to greatly
simplify the work of translators, particularly when doing updates to
translations.
Xavi, EA3W, assures me that all Catalan dialects and variants are
essentially the same, so there's no need to have country variant
specific Catalan translation files.
Xavi, EA3W, assures me that all Catalan dialects and variants are
essentially the same, so there's no need to have country variant
specific Catalan translation files.
Windows makes this more complex than necessary.
On all systems the packaged translation file in the resources
:/Translations directory wsjtx_<lang>.qm will be loaded if <lang>
matches the current system locale. Otherwise the native translatable
strings will be used (en_US is assumed for the native language).
On all systems a wsjtx_<lang>.qm compiled translation file in the
current working directory will be loaded if <lang> matches the current
system locale language and country (wsjtx_en_GB.qm for a locale of
en-GB).
On non-Windows systems the locale used above can be set for just the
wsjtx instance being tested by setting the LANG environment variable,
e.g.
LANG=ca-ES wsjtx
On Windows systems the current locale can only be changed by
installing the relevant Windows Language Pack, selecting the UI
language either as the default or as an
override (Set-WinUILanguageOverride -Language ca-ES) and the signing
out and back in.
The two translations file sources above cam be overridden using a new
command line option:
[-l | -language] <language-code>[-<country-code>]
e.g. -language ca-ES which will load the first readable translation
file as found in the following order: :/Translations/wsjtx_ca_ES.qm,
:/Translation/wsjtx_ca.qm, :/Translations/wsjtx.qm. This search will
be preceded by the normal translation file load from resources
described above. Following that and the normal load from the current
working directory described above, the first readable translation file
as found in the following order: $cwd/wsjtx_ca_ES.qm,
$cwd/wsjtx_ca.qm, $cwd/wsjtx.qm.
This allows Windows testers to change the WSJT-X UI language without
having to change the system UI language and installing the relevant
language pack. Note that using this method will only change the
translated strings, number and date formatting will not change.
Because of this it should only be used for basic testing.
