In response to the previous post, in order to translate a user-made mission or campaign, you would first need to change all the
XSTR("...", -1) to use a unique value (other than -1), then add the translated text to the tstrings.tbl table (making sure you don't blow the upper limit on the table size...)
Ideally, all of the text strings in a mission would have XSTRs which could be translated into any language. But when FRED generates any XSTRs they all have an ID of -1.
It would be nice to extend it so that any text strings in user-generated missions (as well as ship/weapon descriptions) have a unique identifier that could be used for translation purposes.
Currently, as we probably all know, there are two tables for international text:
- strings.tbl which has 1570 strings in English, German and some French (the French translation was apparently never completed.) These strings are extracted from the Freespace2 source files. I am assuming there is/was a script that pulled anything matching "XSTR" in the source and generated this file. Then it was edited before release to add a few extra strings that slipped through. It is mostly UI labels, messages and errors. This file won't need to change unless we add new strings to the source code, or release a new language.
- tstring.tbl has 3421 strings in English and German. These strings were extracted from the missions and from the tables (cutscenes, medals, messages, rank, ships, Species, tips, traitor, and weapons). This file would be need have any translations of mods or user-generated missions
One way we could (maybe) do it would be to reserve ranges of values for the XSTRs in tstrings.tbl:
- 0-4096 reserved (for [V])
- xxxx-yyyy for weapons
- xxxx-yyyy for ships
- xxxx-yyyy for other tables
- xxxx-yyyy for mission and campaign strings
That way the string being generated by mission designers wouldn't collide with those used by ship & weapons modders.
Also, the number of strings and number of languages is (I think) hardcoded somewhere, it would be nice to relax this somewhat and allow an arbitrary number of strings and languages. This would of course require source code changes, both to Freespace and to FRED.
... just some random thoughts, open for feedback