1) Currently, the "Non-English Character Index" field (which, as I said earlier, is for special symbols and not accented letters) takes only one parameter. However, as I pointed out here, font03.vp has the special characters at a unique offset, so there's no way for a HUD gauge that uses special characters to use font03.vp and still display correctly. The "Non-English Character Index" field should somehow be expanded to take three parameters, one for each font.
I don't much like the idea of splitting the special characters field into 3 in strings.tbl. I think that making it a font property defined in fonts.tbl is a better idea. If the setting isn't found, then it falls back to the language default.
I'm currently looking at fixing
mantis 2883. Just to clarify, its not that you don't want to expand "struct lang_info", its more that you want the extra font offsets defined in font.tbl, with the value in strings.tbl to be a "default" value in the case that this info is not defined in fonts.tbl? (although putting the indexes in fonts.tbl sort of makes this value in string.tbl redundant?) If these values are put into fonts.tbl, I think each value will need a corresponding language entry that it refers to. i.e. something like:
#Fonts
$Font: font01.vf
+Language: English
+Special Character Index: 127
+Language: German
+Special Character Index: 164
+Language: French
+Special Character Index: 164
+Language: Polish
+Special Character Index: 127
$Font: font02.vf
+Language: all
+Special Character Index: none
$Font: font03.vf
+Language: all
+Special Character Index: 176 (NOTE: font02 & font03 are based on the only data we have so far, i.e. English & German)
#End
(although I'm not convinced adding the special keyword "all" is worth it, "none" is required due to font02.vf, although -1 could work as well here)
Lastly, if we don't get rid of it, I'll change the "+Non English Character Index:" in strings.tbl to "+Special Character Index".
2) When displaying non-ASCII characters, the game does some remapping from ISO Latin-1 to its own mapping. However, it doesn't do this with the fiction viewer. Because of this, if a default font that supports accented characters is used there, then non-ASCII characters will not display correctly.
I've seen something in the code to do with an umlaut translaction for German (lcl_fix_umlauts), maybe that just needs to be added to the fiction viewer? I think this is worth a new/separate mantis ticket.
3) For this last problem, I'll quote myself on something that we're adding to the next version of FSPort:
Most of the FreeSpace 2 multiplayer missions are still being parsed in the mission simulator. This is a problem because, with the new tstrings.tbl, the XSTR structures for many of their names now point to strings that are longer than 32 characters, causing a boatload of warnings to be thrown in the mission simulator if the language is set to Spanish.
We're going to have to block all the FS2 missions somehow. Right now, we can block single-player campaigns and their missions, but that's it. Perhaps this can be expanded somehow to block single (non-campaign) missions as well as multiplayer missions and campaigns. (If that can't be done, then we could use dummy files...)
So, yeah, the ignore-campaign feature should be expanded to cover single missions and multiplayer missions and campaigns. Also, any XSTR structures found in ignored campaigns and missions should not be translated.
IIRC Goober5000 made some more localisation changes after this feature went in, and I think it involved whether some strings (used as indexes) were translated or not. So, is this still an issue? Also, is there a case to be made for making FSO handle strings longer than 32 chars? Or would that overflow the available space in the interface? Anyway, the ignore-campaign change sounds a bit tricky to me, I don't believe there's anything which associates single player campaigns to single/standalone missions or multiplayer missions.