Language Selection – Talk

Local Code Pages mess

OFP uses ASCII formated text documents, and expects code to be provided as ASCII strings. For the primary western languages, the 'Latin' code-pages generally handle this appropiately. However, when you try to branch out your translations into non-Latin languages, that's where it breaks. Your stringtables files are actually stored as numbers representing the characters intended. Windows then matches the numbers read from the file to a look-up table (code page) to pick a character to send to OFP which then picks a texture portion to render as text. A lot of the non-Latin code pages sort their extended diacritical marks differently, leading to chaos.

An example of this would be attempting to write a stringtables file for english and czech on a machine using a US/UK codepage. If the czech characters look correct when Windows renders it using the western codepage, the czech characters will be scrambled if you attempt to read that same file on a machine using the czech codepage, and also in reverse. Note that this doesn't significantly impact the Latin languages of English, French, German, Spanish, and Italian, but it seriously impacts non-Latin languages such as the Scandinavian and especially the Slavic languages.

Furthermore, the limited character resolution means that there will be no practical solution for East Asian languages in OFP. Workarounds can be made by using resource pictures in place of textual overlays. Additionally, OFP supports right-justification in resources, but does not have proper RTL string handling capabilites.

For editing stringtables for the reasons mentioned above, it's strongly recommended that a Unicode spreadsheet application be used to build and edit the stringtables with final export to the text stringtable.csv files.

Shinraiden 06:23, 20 July 2006 (CEST)