... Threw away one field as unused; found a subtle but inconsequential mistake
in the use of another.
Fields that are stored for the purpose of internal identifiers should be
untranslated. Strings used to form registry keys should certainly be
untranslated. Translations should only happen for purposes of display to
the user.
... A "translated" effect family string, plus "/Enable", was used as a
registry key for lookup! It is wrong to key on a translation.
But in fact exhaustive search for "/Enable" shows that the only such strings
for which a written (by EffectsPrefs) registry value could be found were
AudioUnit
Ladspa
LV2
Nyquist
VAMP
VST
And none of these was actually a msgid in audacity.pot. So nothing bad can
really have happened in other locale settings.
... because I want to make a type distinction later.
Replace calls to GetXXX() without argument, with GetTranslatedXXX() --
this reveals a subtle error, see next commit.
... though the version (like the description) really wasn't yet used for
anything but to write and read again from the registry, still keep writing it.
Because it is appropriate to write untranslated strings to the registry, and
perhaps the values in old registries really will find a future use.
... it was simply written to registry and read again, serving no other
purpose.
But still write a blank to registry for backwards compatibility of the .cfg
file.
This makes it irrelevant whether the value of IdentInterface::GetDescription()
ought to be localized (registry values should probably not be).
Therefore IdentInterface::GetDescription can return localized, and it's all
right that the return be computed (as in VST effects), rather than
an unlocalized msgid that we rely on as an internal identifier.
... Specify an array of arrays of strings. Don't pack it all as a single
string that is parsed. This makes the setup clearer.
It also avoids some concatenations of localized strings (which I want to
make uncompilable some day), and also removes the need for translators to
count the \n's and replicate precisely.
... Avoid small out-of-context words and phrases in translation catalog that
are then substituted into larger translated phrases with blanks.
(What if my language has declensions? How do I know the right form to use
for the phrases?)
Instead, give the translators larger in-context phrases to work with, even if
that requires replications of phrases with small variations.
See original attempt at commit 7ec5fd79df65cd3e54d3d14c52df106d71d06c53
This eliminates the need for a resource file at run-time.
locale/LanguageNames.txt is intended as a "source file" that is infrequently
changed as the set of supported languages changes.
The intermediate step, of appropriately copying that file into the C++ source
code in src/Languages.cpp, was done by hand.
In XCode, I set locale/LanguagesNames.txt and src/Languages.cpp to be
interpreted as Western encoding, and then the copy-paste was easy in the
editor.
The resulting C++ source code file now has string literals that are not 7-bit
ASCII.
This allows us to directly include language name strings in unicode in the file.
The L in the strings ensures wchar_t use.
I've confirmed that this gives the same results visually on Windows,
and that we do get unicode on Linux.
