[L@Zar0]

Hi,

this is my first post in this forums, so I'm not sure if this thread is opened in the correct place. Move it if necessary, please.

Alright. A bit of background first.

I'm a translator for videogames (spanish translator) and contacted with some people of the spanish team that translated FS1 and FS2 into spanish. I'm trying to upgrade the translation in this cases:

1.- Adapting texts to the spanish fonts found in FSPort (witch add áéíóúñ¡¿ chars between a pair more).
2.- Adapting/translating texts of FSPort to FSO (if needed) or updating with new previous chars.

All right. All seems to work well, at least point 1. Written texts with above chars are well displayed. Maybe will be useful uppercase ÁÉÍÓÚ, but I can do the translation with them for now. There are a few words that maybe use this chars.

Apart of it, I'm having some minor problems. I can not translate all texts, or in-game texts appear in english and I can not find where they are.

Right now I found two situations:

a.) When targeting subsystems in hostile (weapons, sensors, communications...) appears the name of the subsystem in the target box, in the lower left panel, right? It gives a % of the subsystem condition.

Well, in this case, I can not find where are the texts for weapons or sensors for example. I've seen in "hudtargetbox.cpp" that only "communications (333) and navigation (335)" have an identifier, but not other subsystems like "sensors, weapons, gas collector, etc...".

Is there somehow to translate this subsystems or are they embbeded in .exe? Will they be updated?


b.) This is a minor issue about keys/key binding. When doing training mission, the instructor asks to press $Left Ctrl$. Obviously I can not translate this, somehow this is embedded also, right? If I put $Ctrl Izq.$, it does not display well the text. Also, sometimes, if another button or key is used, it appear something mixing spanish with english like:

"Pulsa la tecla [LEFT CTRL or button X]", for example. It should say something like "Pulsa la tecla [CTRL IZQ. o la tecla X]"

Is there any choice I can translate "or button" in this case?


There are another issues, like new lines added in FSO not present in strings.tbl, for example some lines above 1569, I add them when I found:
=========================================================
;0000# NOT FOUND IN CODE, "Current Score:" (barracks.cpp)
;0000# NOT FOUND IN CODE, "Quick start" (mainhallmenu.cpp)
1598, "¡Desactivado!\n\nAhora los pilotos en Solo y en Multi son idénticos. Borrar un piloto de multijugador también borrará los datos del piloto para un jugador.\n\nComo medida de precaución, los pilotos solo se pueden borrar en el menú de un jugador."
1599, "Error\nNo se ha podido borrar el archivo del piloto. Puede que el archivo sea de solo lectura."
1600, "No se encuentra la campaña activa actual. Selecciona otra, por favor..."
1601, "¡Desactivado!\n\n\nAhora los archivos de los pilotos en Multi y en Solo son idénticos.\n\nYa no es necesario convertirlos."
1604, "Has seleccionado TCP/IP para jugar al multijugador de FreeSpace, pero el socket TCP ya está en uso.  Comprueba otra instancia y/o usa la opción de línea de comandos para indicar el puerto \"-port <port_num>\" y selecciona uno disponible."
1605, "Introduce el nombre de la misión.\n\n* Esto destruirá todo el progreso legítimo de esta campaña. *"
1606, "El archivo de Campaña actualmente no está disponible"
1607, "Ir a Campañas"
1608, "Selecciona otro piloto"
1609, "Salir del juego"
1610, "¡Desactivado!\n\n\nAhora los pilotos en Multi y en Solo son idénticos. Si borras un piloto en multijugador también borrará los datos de ese piloto de un solo jugador.\n\nComo medida de precaución, los pilotos solo se pueden borrar en el menú de un jugador."
1612, "No se encuentra la campaña activa actual, ¡no se puede cambiar a modo campaña!"
1613, "¡No hay campañas disponibles!"
1636, "Puntuación solo de muertes:" ; 'Score from kills only:' in english
1637, "El piloto seleccionado se creó con un idioma diferente\nal que hay actualmente activo.\n\nSelecciona un piloto diferente o cambia el idioma, por favor."
====================================================

Maybe I will find more issues doing the translation, I will post or comment them here. I hope this helps a bit more coding FSO.

Hope you can help me a bit.

[Yarn]

Maybe will be useful uppercase ÁÉÍÓÚ, but I can do the translation with them for now. There are a few words that maybe use this chars.

Apart from É, those letters are not supported by FSO's internal character set. Once TrueType support is committed, I intend to start work on implementing Unicode support, which will support those characters (and many more).

a.) When targeting subsystems in hostile (weapons, sensors, communications...) appears the name of the subsystem in the target box, in the lower left panel, right? It gives a % of the subsystem condition.

Well, in this case, I can not find where are the texts for weapons or sensors for example. I've seen in "hudtargetbox.cpp" that only "communications (333) and navigation (335)" have an identifier, but not other subsystems like "sensors, weapons, gas collector, etc...".

Is there somehow to translate this subsystems or are they embbeded in .exe? Will they be updated?

Unfortunately, some text (like subsystem names) are hardcoded and cannot be translated to any language other than German, French, or Polish right now. I hope to fix this when I add Unicode support.

It's best if you leave 333 and 335 alone, though. These aren't actually displayed in-game; instead, if a subsystem name matches one of those, then the game changes it to either 334 or 336. It's those two that you want to change.

b.) This is a minor issue about keys/key binding. When doing training mission, the instructor asks to press $Left Ctrl$. Obviously I can not translate this, somehow this is embedded also, right? If I put $Ctrl Izq.$, it does not display well the text. Also, sometimes, if another button or key is used, it appear something mixing spanish with english like:

"Pulsa la tecla [LEFT CTRL or button X]", for example. It should say something like "Pulsa la tecla [CTRL IZQ. o la tecla X]"

Is there any choice I can translate "or button" in this case?

Yeah, key names can't be translated either. I can at least get the "[key] or [button]" text fixed very soon, though.

There are another issues, like new lines added in FSO not present in strings.tbl, for example some lines above 1569, I add them when I found:
=========================================================
;0000# NOT FOUND IN CODE, "Current Score:" (barracks.cpp)
;0000# NOT FOUND IN CODE, "Quick start" (mainhallmenu.cpp)
...
====================================================

I can easily add translation support for those lines too.

[karajorma]

When is truetype support going to be committed? I want to be able to start giving my students homework where they have to translate Freespace into Chinese.



More seriously though, this does bring up an issue. Although we can translate the common subsystem names, we can't do anything about those that only appear in mods and TCs. And hardcoding in support for them isn't the best idea either. We need a way that a mod can have a subsystem called say "Neutron Reactor" and still be able to translate it. We could then hard code that table in for FS2 and dispose of the awful hacky way it's done in hud_targetbox_truncate_subsys_name()

[AdmiralRalwood]

It should already be possible to provide the subsystem's name with an XSTR() that will get translated; whether that will screw with anything else in practice, I don't know (I can easily imagine FRED/SEXP problems related to that).

[karajorma]

It should already be possible to provide the subsystem's name with an XSTR() that will get translated; whether that will screw with anything else in practice, I don't know (I can easily imagine FRED/SEXP problems related to that).

I'm not sure you've quite grasped the problem here. The problem with giving out XSTRs is that they are hardcoded into the exe. So if tomorrow I make a ship and it has a subsystem on it called Docking Crane for instance then there is currently no way to translate that except adding it to the code. Which then means FSO has to support it forever.

Now I know we could just code it so that FSO takes all the subsystems that aren't already hardcoded and adds them to the list of XSTRs. I assume that's what you mean. The problem with that is that you can't use strings.tbl for it (at least not without adding a whole new section). We currently have 1638 XSTRs defined in the code. So a TC would start adding them to the end of the table. So string number 1638 becomes Docking Crane in English and whatever in the other languages that mod supports.

But then a coder comes along and needs to add an XSTR. So they bump XSTR_SIZE by one and add it in. And now all the subsystems in the mod are broken because string number 1638 now points to something completely different. Worse, we'll now get the translated name of the subsystem outputted for whatever message the coder decided to give to XSTR 1638.

To do this, we'd need a new section in strings.tbl (or tstrings, or a new table) with its own unique modifier numbers. We'd then add those to the hard coded XSTRs. That way their XSTR index is assigned at runtime. We'd also need to check for references to XSTR_SIZE and change this to a variable that equals XSTR_SIZE+number of subsystems that are being renamed.

[L@Zar0]

Thanks a lot for the info Yarn. I have suspected that I can not translate this things because they are embedded. So, I think I will translate text that is now in strings.tbl and tstrings.tbl and wait for an update of FSO and translate the remaining texts when possible (TTF support or an update with external strings for this two issues).

I thought that It could be modified easily with XSTR, looking a bit in the code, but if subsystems and keys are used also as vars in code/scripting, this makes the changes a bit more difficult. I asume that I can not do this changes in FSPort Upgrade (without FSO) either, right? They should be encoded also.

c.) Another issue that should be translated also there are the name objects in scripts files (.fs2 missions, for example).
If we have this object name:
Name$: Drone 01

We should translate it into:

Name$: Dron 01 (to make it fancy on screen)

I'm testing this in training missions, for example, and it works if I change all the instances of the text in the script, because it is used as a var also. It has worked, a var is a var, but I don't know if this object name can be used in another external script and if it is recommendable doing so.

d.) One more issue I found is the X,Y coordinates of menu texts (strings.tbl). Somehow, some of the texts are used in more than one place, and it gets justified wrong because the X,Y coordinates are diffent in some cases (like Exit or Help or Option in the bottom right corner of some sections in main hall).

I don't know if there is any form to make it fancy in menus.

[karajorma]

I would definitely not recommend translating the names of objects. The big issue isn't that anything will go wrong with what you're doing but that you basically change the mission file itself. Which then makes you responsible for updating it every time someone changes the mission. For FS1 and FS2 you might get away with that but as the release of Freespace Blue shows, I wouldn't count on it.

[L@Zar0]

I understand the non-translation of Name$ vars. A little change can break all the script (or scripts), but it would be very interesting for translation purposes to make possible modify this Names. Not only in mission .fs2 files, in some .tbl files like ships, ranks, medals or weapons could be very interesting.

In fact, in weapons.tbl, there is the "+Title"/"+Tech Title" section which give to us the possibility to change the in-game visible text, right? Sample of weapons.tbl:

===================
$Name: ML-16 Laser
+Title: XSTR("Laser GTW ML-16", 505)
+Description:
XSTR("Armamento estandar
Danos en casco medio", 506)
$end_multi_text
+Tech Title: XSTR("Laser GTW ML-16", 505)
+Tech Anim: cb_ml16
+Tech Description:
XSTR("Arma laser de Argon - usa tecnologia ceramica transparente con el fin de crear un sistema optico que es extremadamente duradero y estable bajo condiciones de batalla - ofrece un adecuado dano destructivo en el casco de las naves enemigas vaporizando vinculos moleculares en el area seleccionada y desestabilizando vinculos moleculares a traves de las particulas del material del casco.

El GTA monta los lasers ML-16 en cada caza y bombardero en servicio.", 507)
$end_multi_text
===========================

Could I use this section in other tables somehow or do you think that it will be implemented in the future?

PD: I remember now that ranks.tbl has also Name$ with XSTR... hope we can use this method in other files.

[AdmiralRalwood]

The problem with giving out XSTRs is that they are hardcoded into the exe.

http://hard-light.net/wiki/index.php/Tstrings.tbl

[karajorma]

Even if we use TStrings, we're going to have an issue I mentioned about needing a new section in the table. Cause otherwise we have the problem that a mod out there might have extended Tstrings.

[L@Zar0]

I'm sorry if I say something wrong, I'm not a FSO coder, and very new in this forums, but the XSTR IDs could have some type of specifics like:

- Numbers 1-4500: assigned to Freespace/FS2 only, untouchable, including embbeded strings in .exe.
- Above 10000 numbering could be used for mods, for example or a mod could use his own tstrings.tbl, let's say the mods could use something called tstr_m.tbl for strings without touching the assigned tstrings.tbl file. This allows also to use code of original game.

My intention is only to help, my primary goal is to leave translated FS1/FS2 if I can. Right now I've translated strings.tbl and about 1000 lines of tstrings.tbl. But there are remain about 3000 or more lines yet. xD

Also, a very silly question for my part.... Why you do not use ID numbers of strings directly in FSO without using text (and leave text written in .tbl files or another type of external file)?

Do you now about Baldur's Gate .TLK format? It uses this method (IDs assigned to text, but in-game code/scripts uses only IDs).

[AdmiralRalwood]

Even if we use TStrings, we're going to have an issue I mentioned about needing a new section in the table.

...Why? Just add new entries at the bottom of the list.

Cause otherwise we have the problem that a mod out there might have extended Tstrings.

We're still talking about translating FSPort, right? If there's a mod for FSPort out there that provides its own tstrings, it would need translating separately anyway, so I don't see the problem.

[Yarn]

AdmiralRalwood, I think you're confused here. There are two different table files that store translations. Here's how they differ:

tstrings.tbl (or *-tlc.tbm): Stores translations for external strings, such as those in mission and table files. The game code does not reference anything in this table at all, so modders are (to some extent) free to add, remove, or change entries here as they please, provided they don't exceed 4,500 strings.

strings.tbl (or *-lcl.tbm): Stores translations for internal, hardcoded strings, meaning strings stored in the game code itself. Each entry here is permanently assigned to a specific purpose that cannot be changed, and a new entry cannot be added unless the code is updated to make use of it.

[karajorma]

I'm sorry if I say something wrong, I'm not a FSO coder, and very new in this forums, but the XSTR IDs could have some type of specifics like:

- Numbers 1-4500: assigned to Freespace/FS2 only, untouchable, including embbeded strings in .exe.
- Above 10000 numbering could be used for mods, for example or a mod could use his own tstrings.tbl, let's say the mods could use something called tstr_m.tbl for strings without touching the assigned tstrings.tbl file. This allows also to use code of original game.

While not in and of itself a bad idea, this is similar to the kind of thinking had which has caused us no end of troubles. The problem is that although 10,000 might seem like enough now, that number could later come and bite us on the arse in 10 years time. We've had quite a few occasions when a coder has added a limit that seemed like enough only for a mod to later want to break that limit. A dynamic system where the strings are added to the bottom of an array regardless of how big it is is a better idea because it is future proof. No matter how big the number of strings the engine uses, the only limit is the size of the array and that can easily be bumped (or gotten rid of by simply using a vector).

My intention is only to help, my primary goal is to leave translated FS1/FS2 if I can. Right now I've translated strings.tbl and about 1000 lines of tstrings.tbl. But there are remain about 3000 or more lines yet. xD

Want to look at Diaspora afterwards? We've already translated strings.tbl into Spanish but all of Tstrings.tbl is still in English and we'd love to be able to have the game work in Spanish.

No pressure, just that it would be nice if you were interested.

Also, a very silly question for my part.... Why you do not use ID numbers of strings directly in FSO without using text (and leave text written in .tbl files or another type of external file)?

Do you now about Baldur's Gate .TLK format? It uses this method (IDs assigned to text, but in-game code/scripts uses only IDs).

The main reason? Readability I suspect. It is much easier to read something in FRED or in the code if there is an English string to read. Having to constantly refer to a table would be rather confusing and annoying.

[L@Zar0]

I'm sorry if I say something wrong, I'm not a FSO coder, and very new in this forums, but the XSTR IDs could have some type of specifics like:

- Numbers 1-4500: assigned to Freespace/FS2 only, untouchable, including embbeded strings in .exe.
- Above 10000 numbering could be used for mods, for example or a mod could use his own tstrings.tbl, let's say the mods could use something called tstr_m.tbl for strings without touching the assigned tstrings.tbl file. This allows also to use code of original game.

While not in and of itself a bad idea, this is similar to the kind of thinking had which has caused us no end of troubles. The problem is that although 10,000 might seem like enough now, that number could later come and bite us on the arse in 10 years time. We've had quite a few occasions when a coder has added a limit that seemed like enough only for a mod to later want to break that limit. A dynamic system where the strings are added to the bottom of an array regardless of how big it is is a better idea because it is future proof. No matter how big the number of strings the engine uses, the only limit is the size of the array and that can easily be bumped (or gotten rid of by simply using a vector).

Well, it only was a suggestion. I think that would be other methods like make "sections", very similar to "localization" sections in tstrings.tbl (#default, #German, #French...) and improve FSO with another keywords. So, this keywords (even the IDs could begin in 1), for example: #master, #mod...  would be exclusive to the original/mod for new things added.

My intention is only to help, my primary goal is to leave translated FS1/FS2 if I can. Right now I've translated strings.tbl and about 1000 lines of tstrings.tbl. But there are remain about 3000 or more lines yet. xD

Want to look at Diaspora afterwards? We've already translated strings.tbl into Spanish but all of Tstrings.tbl is still in English and we'd love to be able to have the game work in Spanish.

No pressure, just that it would be nice if you were interested.

Sorry, I do not know Diaspora (or another things posted like Freespace Blue). Now I'm focused only with Freespace. Opening more things is not good idea for me. First things first.

I'm in contact with one of the former spanish translation, darkpadawn, I know him and I have said to him I'm doing this. He will try to talk with Alex Navarro, the original and former spanish translator of the group. I assume that the lines added to strings.tbl and tstrings.tbl you have are from their translation.

The translation I'm doing consists on 2 things (this includes both .tbl files, I have decided to not translate original .tbls or .fs2 files):
- Review and spellcheck original translation comparing it with english one (I've seen there are some texts changed from the time it was done). This includes update spanish texts with áéíóú¡¿ñ character set. In that time the fonts where inexistent as I've been told.
- Translate things not translated. There are a BUNCH of new .fs2 files. Their translation had 54 .fs2 files. FSO has more than 154 missions. There are also some lines in strings.tbl that are not translated in #Spanish section. This will take a bit of time.

Maybe the translation for the actual texts takes me about 2-3 months, but I don't know for sure. I want to do some testing also in-game. Let's see if some of the former translators can help me. Also, there will be some things remaining untranslated until modified in FSO, like things I've been posted in this thread in my previous posts. In Briefing, for example the cutscenes have names (like Freighter, Drone), that should be translated (Carguero, Dron), but it is impossible right now to do so if they are not changed in .fs2 files. Another things to remain unstranslated will be medals, ship names and key/key binding.

I understand the reability thing in the last point. But I think that once a thing is done you don't need to touch it (you can leave a comment with the original english text in .cpp file to know what is refering the ID also). I'm thinking on the user that whants to translate to chinese FSO... :O Unicode would be necessary absolutely. If you have IDs only... there is no need to touch .exe, only external file with strings. Some parts of the .exe has foreign english languages (like german or french) embedded, this could be all externalized. But well, it is only my opinion in this case.

[karajorma]

You're right about externalising the other languages for unicode. I fully agree and support the idea that you should be able to localise into any language. I was referring to why everything in the code looks like this

Code: [Select]

popup( PF_USE_AFFIRMATIVE_ICON | PF_NO_NETWORKING, 1, POPUP_OK, XSTR( "You have not defined your type of Internet connection.  Please run the Launcher, hit the setup button, and go to the Network tab and choose your connection type.", 360));
Rather than simply like this

Code: [Select]

// undefined type of Internet connection.  Warn user how to use Launcher.",
popup( PF_USE_AFFIRMATIVE_ICON | PF_NO_NETWORKING, 1, POPUP_OK, XSTR(360));
I assure you that from a maintenance point of view, the former is much, much easier to read and deal with.



As for Diaspora, I did say afterwards. As in, after you're done with FS1 and FS2 if you still feel like translating something. I agree that it's not something you should start doing now.

Well, it only was a suggestion.

Don't get me wrong, I wasn't upset with your suggestion or anything. I just prefer to give a clear answer why something might not work so that there's no confusion.

[L@Zar0]

Well, it only was a suggestion.

Don't get me wrong, I wasn't upset with your suggestion or anything. I just prefer to give a clear answer why something might not work so that there's no confusion.
[/quote]
It's ok, i'm only giving suggestions, that's all. I will leave the FSO work for you.
Ok, I will let you know when I have translated actual tstrings.tbl.

[AdmiralRalwood]

AdmiralRalwood, I think you're confused here. There are two different table files that store translations. Here's how they differ:

I'm well aware of how they differ; we're talking about strings in tables. Specifically, ships.tbl. Specifically, we're talking about the names of subsystems in ships.tbl. Hence why I'm talking about tstrings, and confused why Karajorma seems to think we'd need to add new sections to the file format.

[Yarn]

I'm well aware of how they differ; we're talking about strings in tables. Specifically, ships.tbl. Specifically, we're talking about the names of subsystems in ships.tbl. Hence why I'm talking about tstrings, and confused why Karajorma seems to think we'd need to add new sections to the file format.

I looked at the ships.tbl documentation again, and it looks like $Alt Subsystem Name can be used to allow translation of subsystem names, as long as the modder uses an XSTR structure there. It's an SCP addition, though, so it's not present in the retail tables.

You had us confused there because we were discussing the "main" way that FreeSpace translates subsystem names: a hardcoded list that only translates certain names to certain languages (with the exception of "communications" and "navigation", which can be freely translated via strings.tbl), and we thought that you were suggesting that we expand that list. I and perhaps Karajorma weren't aware of $Alt Subsystem Name.

[AdmiralRalwood]

Thank you for reminding me about the existence of hud_targetbox_truncate_subsys_name(), which I had actually managed to forget existed... probably because it is The Worst™.

But on the plus side, I have been reminded that "fighterbay" gets translated as "Jågerhangar".