Passing `--language en', '-l en-US', or `-l en_US` now takes a special
action to not load any translations using the current locale. This
allows the current system UI language not to influence an translations
loaded via the command line override when the native en-US is wanted.
This allows the Spanish UI translation to work, for now, for all
Spanish speaking locales. If necessary we can make it es-ES if other
translators feel it is not a good base for their Spanish variant. OTOH
if they just need to l10n a few strings then, say for Argentina, then
they can do that in an wsjtx_es_AR.ts and untranslated strings there
will fall back to the ones in wsjtx_es.ts automatically. This happens
because of teh way the application loads multiple translation files in
an order suitable for that to happen.
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.
Re-enabling the WSJT-X i18n facilities. This allows translation files
to be created for languages that are automatically used to lookup
translatable strings. To enable a new language the language name must
be added to the CMakeLists.txt LANGUAGES list variable in BCP47 format
(i.e. en_US, en_GB, pt_PT, ...). Do one build with the CMake option
UPDATE_TRANSLATIONS enabled (do not leave it enabled as there is a
danger of loosing existing translated texts), that will create a fresh
translations/wsjtx_<lang>.ts file which should be immediately checked
in with the CMakeLists.txt change. The .ts should then be updated by
the translator using the Qt Linguist tool to add translations. Check
in the updated .ts file to complete the initial translation process
for that language.
To aid translators their WIP .ts file may be tested by releasing
(using the lrelease tool or from the Linguist menu) a .qm file and
placing that .qm file in the current directory before starting
WSJT-X. The translations will be used if the system locale matches the
file name. If the system locale does not match the file name; the
language may be overridden by setting the LANG environment variable.
For example if a wsjtx_pt_PT.qm file is in the current directory
WSJT-X will use it for translation lookups, regardless of the current
system locale setting, if the LANG variable is set to pt_PT or pt-PT.
On MS Windows from a command prompt:
set LANG=pt_PT
C:\WSJT\wsjtx\bin\wsjtx
elsewhere:
LANG=pt_PT wsjtx
The tool record_time_signal is designed to measure the performance of
QAudioInput. The intended use is to record a short period of live
audio from an on-air time signal of known good quaility, the basic
required parameters are an audio input device, an output file name
(.WAV), a start second in a minute, and a duration in seconds. So for
example to record the time signal ticks and fast data at the top of
the minute:
$ record_time_signal -o wwv.wav -s 55 -d 15
will record 15s of audio at 48000Hz sample rate, stereo, from the
default audio input device, starting at second 55. This will use a
separate timer to stop the recording which is likely to leave the
output file a little short due to buffer latency. The buffer size can
be adjusted using the '-b <buffered-frames>' option.
The tool also supoorts a different mechanism to time the recording
which uses the audio progress via a notify signal. This should ensure
at least the requested duration is recorded The shorter the notify
interval the closer teh final size shoould be to the requested
duration. Use the '-d <interval-ms>' option to adjust the notify
interval.
$ record_time_signal -o wwv.wav -s 55 -d 15 -n 100
Non-default audio devices can be selected, use the '-I' option to list
the available input devices with an index number that can be used to
select the device using the 'R <device-number>' option.
Other options are available, use '-h' for details.
