There seem to be some errors in .po compilation, I'll take a look at them.

Lots of newline mismatch complaints. It would be best to correct all of of this in the Crowdin sources, of course. Hmm.

I think the root cause here is that translatable messages should not end with \n at all. I can see that lots of them belong to LogError(), which doesn't really need a trailing newline. It resolves to either NOUI_LogError(), which adds \n to stderr anyway, or UI_LogError(), which always removes it.

These newlines are translators' nightmare - they don't show up properly in Crowdin, and can only be spotted through an obscure and unreliable "QA" mark

Looks like Crowdin ignores whitespace changes (such as added or removed newline) when uploading translations. The only thing I could do so far is deleting the string altogether and re-uploading it again. Unfortunately it deletes the provenance, which is not good.

Maybe add the newlines back as a post-processing step?

I'm trying to automatically remove as much trailing newlines as I can, this is quite a pain. I'll see if this reduces the number of error to a manageable amount

Open-up KDE Kwrite, it's a pretty good text editor. Set the settings to remove trailing spaces on entire document. Load the po file, add a space, to update, then save, the entire document should have all trailing spaces removed.
I think Notepad+ (or Notepad++) does similar if you run windows.

The problem is unfortunately much worse than that. We have msgids (source strings) which are harvested from the source code. Some of them have trailing \n, and some of them don't. Those which do have trailing newline, must be translated with a trailing newline too. Those which don't have it, must be translated without. Otherwise the gettext compiler complains.

Even if I do align all this stuff manually, the problem will recur. The Crowdin interface doesn't emphasize the trailing newline. One must be pretty technical to notice the newline presence or absence and spot this additional line break which is only manifested by cursor placement.

Basically I'm trying to strip as much trailing newlines as possible, as most of them are already meaningless - the software normalizes them anyway.

Also, stripping them in our source doesn't help. Crowdin doesn't recognize this change and silently discards translations whose msgid was changed by removing thew newline.

A summary of fixing procedure: https://github.com/iorsh/fontforge/wiki/Crowdin-fix . We are destined to suffer...

...while making updates on designwithfontforge, I was running into some wild behaviour with Farsi's right to left, so that's yet another thing to look forwards too ;-P

perhaps ssome thinking outside the box is needed here....
I just finished contributing to another project which had some different way of writing text, it seemed a bit verbose, but might help here in this case....

What I was seeing looked something like this:

printf("blah, blah, blah\n"
       "\n"
       "blah, blah, blah\n"
       "\tblah, blah, blah\n"
       );

so perhaps adapting to consider crowdin and newline issues....

/* string below is:
 * blah, blah, blah value1 value2
 *
 * blah, blah, blah
 *          string1 blah, blah, blah
printf(_("blah, blah, blah %d1 %d2"),value1, value2);
printf("\n\n");
printf(_("blah, blah, blah"));
printf("\n");
printf(_("\t%s blah, blah, blah", string1));
printf("\n");

This turns into a crazy verbose, and sort of hard to read string as a developer, but probably low (or lower) maintenance in the long run as you wouldn't need to come revisit and remodify per update.
You'd need to include tabs inside the translation, because Farsi would go right-to-left.

maybe something to think about?

Newlines and inline formatting are generally considered a bad practice in localization.
What I would do is

/* Comment for readability... */
char title[100], *paragraph = _("blah, blah, blah"), tab[100];

sprintf(title, _("blah, blah, blah %d1 %d2"),value1, value2);
sprintf(tab, _("%s blah, blah, blah", string1));

printf("%s\n\n%s\n\t%s\n", title, paragraph, tab);

Otherwise you end up with twenty different approaches to each formatting challenge, as different languages are usually translated by different people.

Btw, @JoesCat, feel free to poke me about RTL issues at designwithfontforge. That stuff is not new to me :)

You're almost there.... I ran into issues earlier (with plugin-gimp-fourier and gimp-fix-ca) and discovered you'd also need to handle xgettext with one set of data, and gettext with the printf() stage. What worked, was to split it in 2 stages. My solution for the 1st stage was to do something like this:

/* Comment for readability... */
char title[100], *paragraph = d_("blah, blah, blah"), tab[100];

...so, for the above, xgettext finds the string, and I needed to add a new something for xgettext, in this case, was adding d_
this lets you compile the code as expected...and then to make the second stage work, you still need gettext to work with printf, so it probably should look like this instead:

printf("%s\n\n%s\n\t%s\n", title, _(paragraph), tab);

Btw, @JoesCat, feel free to poke me about RTL issues at designwithfontforge. That stuff is not new to me :)

Thanks! If you want to poke at designwithfontforge, go ahead, but I suspect your plate is pretty full as-is right now ;-P

At the moment, think I've managed to clean-up the 1st 1/3 to be all synced-up, but have yet to go through the last 2/3rd syncing and cleaning up. I also expect there's several "new" pages that need to be synced from Japanese to the other languages. Far too much to do all in one shot - and the break in between helps. ...however, 1st-thing-1st, I need to get some exercise first! Time for a walk....

Opened skef#1 into this branch. @skef, could you please check if you have time? I can open PR directly into fontforge/master, if that's easier.

I'll check in a bit