Hi Paul
First of all: the Dutch translations are completed on Transifex! 😊
Second: my username on Transifex is RockyTDR, and I made the comment.
What I meant is the following. Transifex "recognizes" html and some other tags.
It allows translators to copy e.g. "<a href..." as some kind of "balloon".
The problem is that Transifex treats some characters, or the order of some
characters (1%F for example) as a "balloon". Translators are obliged to use
that same "balloon" in their translations. If not, it returns an error.
This is what I mean (Transifex screenshot):
[cid:d097c4fa-6b8d-49a1-b402-0aa99c7086c8]
In this case the "F" of "Frequency" is recognized as a tag. This can be solved
by putting a space between characters, like this: "1% F".
I hope this clears things. If you have any questions, i'd be happy to answer
them.
Regards
Thomas De Rocker
________________________________
Van: Paul Licameli <[email protected]>
Verzonden: donderdag 8 maart 2018 20:20
Aan: audacity-translation; Thomas De Rocker
Onderwerp: Re: Lisp formats are not C formats
On Thu, Mar 8, 2018 at 1:55 PM, Paul Licameli
<[email protected]<mailto:[email protected]>> wrote:
I got this notification from Transifex, forwarding a query from one of you, and
not sure how to respond at that site, so I write to this mailing list:
"
Error:~%~%Frequency (~a Hz) is too high for track sample rate.~%~%~ Track
sample rate is ~a Hz~%~ Frequency must be less than ~a Hz.
1%F is recognized as placeholder - no problem for Dutch translation because
"frequentie" (nl) starts with f like "frequency", but maybe other languages
will have problems.
"
Either I misunderstand the report, or the translator does not understand that
this is a Lisp-format string, not C-format. So % does not have the usual
meaning.
The Lisp function called format changes ~% to a newline, so ~%Frequency becomes
just a newline and then the word -- no relation to the C format %f sequence.
Also ~~ becomes ~, and ~ followed by newline is just a break in the string to
make the format easier to read, and is simply deleted, with following
whitespace characters, by format.
The ~a sequence is the only placeholder. Unlike with C, there is no need in
Lisp to distinguish placeholders for strings and for numbers with different
sequences.
Or is it the .po file editor that is misunderstanding the input and making some
incorrect warnings about this string? Perhaps then there is a better editing
program to use instead!
You should also know: there are special generated comments in the .pot file,
that are supposed to identify format strings:
#, c-format
#, lisp-format
These comments are used in the build to check that the number of placeholders
in the msgid equals that in the msgstr.
Perhaps a good .po file editor is sensitive to these lines?
I checked this example, and one other that the translator mentioned, and indeed
the audacity.pot has a #, lisp-format comment, not #, c-format, so I hope your
editor is good enough not to misinterpret the message as c-format when it is
clearly marked otherwise.
PRL
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-translation mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/audacity-translation
