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.
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.
This could make help text windows bigger than the screen, if we want
to go there then using a QLabel sub-class will need to change,
probably by using a read-only QTextEdit instead as that provides
scroll bars. Maybe consider a multi-column table for the contents as
an alternative to scroll bars.
This could make help text windows bigger than the screen, if we want
to go there then using a QLabel sub-class will need to change,
probably by using a read-only QTextEdit instead as that provides
scroll bars. Maybe consider a multi-column table for the contents as
an alternative to scroll bars.
