... That is, present translators with msgids containing only the descriptions
of the file types. No punctuation.
This eliminates the last wxFileDialog, replacing it with FileDialogWrapper.
Silence Finder now throws an error if selection too long.
UI updated to use negative dB consistent with all other shipped effects.
Use max of channels for stereo tracks rather than sum of channels.
Avoid resampling track twice.
Update to version 4 syntax.
Remove Debug button, consistent with other shipped effects.
It's still has some work, but it successfully builds on
all 3 main platforms. Some of the outstanding items
include:
Install target testing (mostly important for Linux)
CMakeList clean up and comments
Debug and Release build verification
Audit of compile/link options
Need a Mac signed and notarized build
(and probably more)
Ran "autoreconf --force --no-recursive" for Linux build.
Add nyquist-plug-in-installer.ny to Windows build
Add Nyquist Plug-in Installer to mac build
Fix translation strings in plug-in installer
... The \t escape is changed to tab by the XLisp reader, but that is not
standard Common Lisp behavior, which would just strip the \ character and leave
t.
xgettext follows standard behavior when making the .pot file, so using \t
caused a mismatch between the catalog and the string actually looked up,
resulting in a translation failure.
There was only one occurence of \t in translatable strings in all of plug-ins.
I left alone the occurrences in non-translatable strings.
Mostly consistency updates, plus a couple of minor fixes.
Line breaks in translated control text strings do not work, so have
been removed.
Obsolete ";categories" commands removed, and ";info" commands replaced
with standard Lisp comments.
... Because xgettext will just remove the \, not replace \n with newline.
That's consistent with Lisp reader behavior in this documentation:
http://www.lispworks.com/documentation/lw70/CLHS/Body/02_de.htm
The XLisp reader, which replaces \n with newline, is nonstandard.
So, to accommodate xgettext, use (format nil "...~%...") instead, or where
you can't do that in a $ header line, just make a line break inside the ""
There are a few "\n" left alone in sample-data-export.ny which are neither
in $ lines nor inside (_ "...")
... The code that parses the header was always just throwing them out.
The code that populates menus deduces whether to add ellipses, as there are
controls or not, regardless what the $name line said.
... The rule that one should avoid markup in translatable strings conflicted
with the more important rule against concatenating too many strings that are
too short.
