Four translations are currently unbuildable

[Andrew Bird]

As noted here a01f824 the Serbian and two flavours of Yugoslavian cause the parsing tool to segfault and with Turkish it generates invalid 'C' code. This was seen with both Github Actions CI and locally here on Ubuntu 20.04. I'm not really familiar with the language handling myself, perhaps someone else can fix this.

Fixes applied

• turkish
• serbian
• yu437
• yu852

[Andrew Bird]

Here's the invalid C code from the Turkish translation

ia16-elf-gcc -mcmodel=small -c *.c
str00ff.c:1:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘i’
 const char PROMPT_CANCEL_toplu i�[] = {
                                ^
str00ff.c:1:33: error: stray ‘\237’ in program
 const char PROMPT_CANCEL_toplu i�[] = {
                                 ^
str0100.c:1:35: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘i’
 const char TEXT_MEMORY_CTXT_toplu i�[] = {
                                   ^
str0100.c:1:36: error: stray ‘\237’ in program
 const char TEXT_MEMORY_CTXT_toplu i�[] = {
                                    ^
make: *** [gnumake.mak:10: strings.lib] Error 1

And in the turkish.lng file

# This prompt MUST include the pseudo key CBREAK!                               
# Note: This prompt ignores DOS NLS intentionally in order to                   
# keep interactive prompt & user-interaction in sync.                           
# Attention: This prompt is used via BIOS; any newline MUST be prefixed         
#       by \r!                                                                  
# Return value: a -> Yes; b -> No; c -> All; else -> Undefined                  
:PROMPT_CANCEL_toplu i<9f>#1%                                                   
YyNnAaQq{LF}{CR}{CBREAK}{ESC}                                                   
aabbcccc   a   a       c    b                                                   
Control-Break'e bas<8d>ld<8d>.\r                                                
'%s' toplu i<9f> dosyas<8d> sonland<8d>r<8d>ls<8d>n m<8d> (Evet/Hay<8d>r/T<81>m<81>) ? \
.                                                                               

That toplu i<9f> in the label name looks wrong?

[Andrew Bird]

See be66413#r45886346 for where it was introduced. Maybe we can just replace the labels that have toplu i<9f> with BATCH?

[Andrew Bird]

This fixes the build, but are the rest of the translations still correct?
andrewbird@ea792b5

[Andrew Bird]

I think @bitigchi was the original translator, can you confirm that the rest of the translations which have toplu i<9f> in them are correct please?

[Emir SARI]

"toplu iş" is correct. Anything I can do to help?

Ah, I see it now. It looks like my mistake while bulk replacing. I'll fix it.

[Andrew Bird]

Cool, thanks you just did! I'll see about getting that in a PR. I don't know how familiar you are with the .lng file format but can you spot anything wrong with the Serbian and Yugoslavian

[Andrew Bird]

If you like to, but I did make the change already in that commit I pointed to.

[Emir SARI]

If you like to, but I did make the change already in that commit I pointed to.

Thank you!

[Andrew Bird]

So the problem for Serbian and Yugoslavian translations appears to be empty strings in the file become NULL pointers in the fixstrs, hence the segfault. I tried looking at the fixstrs source but can't figure out where the problem is exactly. With andrewbird@b521a4b it builds okay for each, but ideally we'd want those translated properly. I also note that the problem strings are not in DEFAULT.lng, only the translations.

[Andrew Bird]

PR coming.