from Issues on translating default plugins - #2 by steve
Please confirm if this occurs with all multi-line strings, or just some.
I checked all translatable multi-line strings in the *.ny plugin files and here is the result.
A short conclusion is: not all, but most.
| | Condition
Plug-in file name | Strings with multiple lines | OK!: Shown as translated
| | NG : Shown staying in English
-------------------------+--------------------------------+--------------
adjustable-fade | Out of dB range error | NG
equalabel | - | (I can't use)
highpass | Too high frequency error | NG
lowpass | Too high frequency error | NG
notch | Too high frequency error | NG
rhythmtrack | Bar#=0 and duration=0 error | OK!
sample-data-export | Full head | NG
| Credit on html footer | OK!
sample-data-import | File absence error | NG
| Non-ASCII error | NG
| Non-number error | NG
SpectralEditMulti | Zero-width band error | NG
| Notch filter error | NG
SpectralEditParametricEQ | Too high freq selection error | NG
| Zero-width band error | NG
SpectralEditShelves | Zero-width band error | NG
vocalrediso | "Average x: ~a, y: ~a" ... | * 1
| Analyzation results | NG
vocalremover | "View Help" message | OK!
| Non-stereo error | OK!
| Too narrow stopband error | * 2
* 1. I have no idea where I can see this.
* 2. I couldn't meet this error even when I tried below two settings I feel narrow:
- "Remove Vocals", "Remove Frequency Band", 10.0, 10.1
- "Remove Vocals", "Remove Frequency Band", 10000.0, 10001.0
As a test, please try replacing the “adjustable-fade.ny” file with this version and then make a new translation for it.
adjustable-fade.ny (7.72 KB)
Deleted blanks at the beginning of lines?
It resulted in success, with some additional steps.
- Replace adjustable-fade.ny file simply
→ NG - In addition, open ja.po on Notepad++ (a text editor), remove that blanks of appropriate original text, save it, open ja.po on Poedit and “Compile to MO…”
→ NG - In addition, open ja.po on Notepad++, edit “t-6 dB” to “\t-6 dB” on appropriate original text, save it, open ja.po on Poedit and “Compile to MO…”
→ OK!
Finally, from:
#: plug-ins/adjustable-fade.ny
#, lisp-format
msgid ""
"~adB values cannot be more than +100 dB.~%~%~\n"
" Hint: 6 dB doubles the amplitude~%~\n"
" t-6 dB halves the amplitude."
to:
#: plug-ins/adjustable-fade.ny
#, lisp-format
msgid ""
"~adB values cannot be more than +100 dB.~%~%~\n"
"Hint: 6 dB doubles the amplitude~%~\n"
"\t-6 dB halves the amplitude."
Perhaps “\t” string on the original *.ny plugins shall be ripped as plain “t” when audacity.pot template file is generated by the Audacity developers.
I wonder *.ny files should have tab character as “\t”, “~t”, tab itself or something else.
Anyway thanks for your test file.
Good work Phroneris 
In a normal Nyquist string “\t” is “tab” character, but the translation process is (incorrectly) stripping the backslash.
The minus sign “-” belongs with the “6” for “negative six”.
Also, in a normal Nyquist string, “~%” means “new line”, and “~” means “continue the string on the next line, ignoring leading spaces”.
It seems that these format specifiers are not being handled correctly by the translation mechanisms. I’ll log it as a bug.
Hello, I’m one of the developers.
I figured out that there was a bug in Audacity 2.3.0. If a .ny file contains a translatable string which includes a line break, and at least one space or tab immediately after the break – then the translation catalog will contain the string, but when the program runs, it fails to find the string because it looks up with the spaces stripped out.
I observed this failure using French language and High-Pass filter, entering a too-large frequency value and getting an error in English.
I am confident that a change in 2.3.1 alpha, at commit 0fbea5f9ea669cd9202d32df8a8bdd6b18ef4c92, is enough to fix this.
Phroneris, you will have to take my word about that – meanwhile you must use a 2.3.0 binary without the fix.
About escaped characters, \n and \t:
These simply should not be written as such in the .ny source files inside translated strings. The “error” is writing them that way. They are not part of standard Lisp, although Audacity’s Lisp interpreter supports them. Yet xgettext, which generates audacity.pot, follows standard Lisp string formatting and is “correct” to reduce \t to t and not a tab character.
In version 2.3.0 I made sure to eliminate \n in such strings, but I missed the \t . Now I have removed it from the 2.3.1 version of adjustable-fade.ny and there are no other occurrences of \t in translated strings.
“Nyquist” is not “standard Lisp”. It is a a re-implementation of Fugue by Chris Fraley.
Both “\n” and “\t” are supported in standalone Nyquist, and have been supported in Audacity for the past decade. The new kid on the block is your translation code, which is not standard Nyquist.
From the Fugue Reference manual:
Literal strings are sequences of characters surrounded by double quotes. Within quoted strings
the ‘‘\’’ character is used to allow non-printable characters to be included. The codes
recognized are:
• \ means the character ‘‘\’’
• \n means newline
• \t means tab
• \r means return
• \f means form feed
• \nnn means the character whose octal code is nnn
Regarding strings containing line breaks followed by spaces:
I have changed the C++ side so that the spaces ARE significant to the Lisp interpreter, so that the string looked up agrees with the string in the message catalog.
But formerly the spaces WERE NOT significant, so it was not the intention of the writers of the .ny files that they be part of the output.
Therefore, I suggest that we ALSO modify existing .ny files to remove those spaces. But then we must regenerate audacity.pot and get translators to update the .po files.
Afterward, newly written .ny files can add new strings with embedded newline-space if that really is the intention.
Do you agree, Steve?
I’m pretty glad to hear it’s confirmed and fixed, especially about blanks just after a line break.
Thanks Steve and Paul!