Hi. I want to translate Order of Ecclesia. I read some guides and tried some tools but with no luck. I found some Portuguese Translations of the game, so it can be translated. Can you tell me which tools I have to use to translate it? Thanks!
For anybody wondering, yes, he is looking to translate it from English to Greek.
Just making that clear before somebody runs in and acts stupid.
Just making that clear before somebody runs in and acts stupid.
For this post I do not have the rom in front of me, as you probably guessed .dat and .bin are common extensions used across computing and offer no real information as to their content in this case (and most cases). As a rule simple tools do not exist and most hackers will roll their own for a given game, convert things to work at some level with some other tools or work keeping things at a fairly abstract level. I am going to find it difficult to cover this without covering hacking concepts and it will be a very quick skim of them as well.
You say there was a Portuguese translation of the game- personally I would grab that and compare files between the game. Files changed there presumably contain the changed text which saves you a little bit of hassle having to find it.
In your case you are most likely going to have to find the font and edit that- Greek characters tend not to be included in the font save perhaps a small subset of them (them being used in science a fair bit) and that is more likely ancient Greek than modern. The Portuguese translation might have seen the font edited to add diacritics but sometimes translation teams ignore them and it might have been able to pull enough from other languages that use such things. However you might get lucky here- the DS SDK has a font standard many games use (although the number at a gut guess hovers around 60% at best) call NFTR which http://gbatemp.net/t105060-nftr-editor? and crystaltile2 can handle. Otherwise it tends to be a simple picture font.
That over assuming you are not going to roll your own tool for text and the game has not made it easy you get to do things. Computers only understand binary/hexidecimal so we have methods of encoding characters in hex- ASCII being a common one, unicode another (although it derives from others), shiftJIS for Japanese and EUC-jp again for Japanese (shiftJIS is very common in DS games and EUC-JP is certainly worth knowing about for DS games) but games have a long history of making up their own encoding method. You gather the encodings in a small file known as a table (several standards here but hey) which a specialised hex editor (have a look around http://www.romhacking.net/?category=13&...itle=&desc= and you should find a couple) or crystaltile2 if you prefer instead ( http://gbatemp.net/t73394-gbatemp-rom-hack...p;#entry2641950 and http://gbatemp.net/i...opic=291274&hl= have some usage) can open and export in a more common method if you like. Some rom hackers all do things like replace whatever a game uses for a new line to something more common and if it has any placeholders making sure they are suitable as well (character names, date, amount of money for an item......).
Of course this does not cover finding out the encoding for which there are many methods assuming you need to find it. There are many methods here ranging from relative search ( http://www.romhacking.net/utils/513/ - the idea being that a word like bad would have have a sequence that varied 1, -1, +3 somewhere in the section, search for a phrase seen in the game and if it is in fact a relative encoding (the Japanese alphabet has no real order) and not compressed it pretty much gives you the encoding there and then give or take capitals and punctuation which is now simple enough to find*), * "?ne day I walked down the street" and you can probably guess the ? is in fact a O either through language knowledge or playing the game- you now have O and presumably all the other upper case letters), brute force- find the text somehow and add in patterns to figure out what goes and note it all down or if you like you can pull apart the rom's code and figure out how it all works to name just a few methods.
Onto pointers now- I covered some earlier today http://gbatemp.net/t...slation-problem but in general the idea is that games do not want to have to detect where a section starts and finishes during the game so lists of values in various forms can exist. I usually compare pointers to the index/contents page of a book. Some games or sections of games use fixed length sections- it will start the next section after ? characters regardless and some games do actually properly parse text but most of the time the values are points from the start of the file, some location within the file or relative to that point in the file ("from this point go ten spaces" sort of thing). Formats will often have similar things indicating the length of sections in the file which you also get to edit. On occasion other things like markup can be found in the pointers to tell the game to do something like bold the text.
Text in images on the other hand (it happens quite often- especially for simple things/sprites) is taken care of with a tile editor and such, some basic image editing was covered http://gbatemp.net/t...-pac-files-help (read the text stuff if you like but the scripting thing was something very rare on the DS). Same applies if you font turns out to be an image.
I hope nothing is compressed- compression it not half the issue it is on earlier systems. Again crystaltile2 has some support and most compression is fairly standard (to the point we have tools like http://code.google.com/p/dsdecmp/ ). Equally I hope no text is contained within the binary (the rom is one thing but there are sections- arm9.bin arm7.bin and the overlays that are loaded into memory that contain the games code and often some other stuff as well) so if remember pointers they are even more fun in the binary as you are addressing them directly in memory and probably finding a way to get some space.
You say there was a Portuguese translation of the game- personally I would grab that and compare files between the game. Files changed there presumably contain the changed text which saves you a little bit of hassle having to find it.
In your case you are most likely going to have to find the font and edit that- Greek characters tend not to be included in the font save perhaps a small subset of them (them being used in science a fair bit) and that is more likely ancient Greek than modern. The Portuguese translation might have seen the font edited to add diacritics but sometimes translation teams ignore them and it might have been able to pull enough from other languages that use such things. However you might get lucky here- the DS SDK has a font standard many games use (although the number at a gut guess hovers around 60% at best) call NFTR which http://gbatemp.net/t105060-nftr-editor? and crystaltile2 can handle. Otherwise it tends to be a simple picture font.
That over assuming you are not going to roll your own tool for text and the game has not made it easy you get to do things. Computers only understand binary/hexidecimal so we have methods of encoding characters in hex- ASCII being a common one, unicode another (although it derives from others), shiftJIS for Japanese and EUC-jp again for Japanese (shiftJIS is very common in DS games and EUC-JP is certainly worth knowing about for DS games) but games have a long history of making up their own encoding method. You gather the encodings in a small file known as a table (several standards here but hey) which a specialised hex editor (have a look around http://www.romhacking.net/?category=13&...itle=&desc= and you should find a couple) or crystaltile2 if you prefer instead ( http://gbatemp.net/t73394-gbatemp-rom-hack...p;#entry2641950 and http://gbatemp.net/i...opic=291274&hl= have some usage) can open and export in a more common method if you like. Some rom hackers all do things like replace whatever a game uses for a new line to something more common and if it has any placeholders making sure they are suitable as well (character names, date, amount of money for an item......).
Of course this does not cover finding out the encoding for which there are many methods assuming you need to find it. There are many methods here ranging from relative search ( http://www.romhacking.net/utils/513/ - the idea being that a word like bad would have have a sequence that varied 1, -1, +3 somewhere in the section, search for a phrase seen in the game and if it is in fact a relative encoding (the Japanese alphabet has no real order) and not compressed it pretty much gives you the encoding there and then give or take capitals and punctuation which is now simple enough to find*), * "?ne day I walked down the street" and you can probably guess the ? is in fact a O either through language knowledge or playing the game- you now have O and presumably all the other upper case letters), brute force- find the text somehow and add in patterns to figure out what goes and note it all down or if you like you can pull apart the rom's code and figure out how it all works to name just a few methods.
Onto pointers now- I covered some earlier today http://gbatemp.net/t...slation-problem but in general the idea is that games do not want to have to detect where a section starts and finishes during the game so lists of values in various forms can exist. I usually compare pointers to the index/contents page of a book. Some games or sections of games use fixed length sections- it will start the next section after ? characters regardless and some games do actually properly parse text but most of the time the values are points from the start of the file, some location within the file or relative to that point in the file ("from this point go ten spaces" sort of thing). Formats will often have similar things indicating the length of sections in the file which you also get to edit. On occasion other things like markup can be found in the pointers to tell the game to do something like bold the text.
Text in images on the other hand (it happens quite often- especially for simple things/sprites) is taken care of with a tile editor and such, some basic image editing was covered http://gbatemp.net/t...-pac-files-help (read the text stuff if you like but the scripting thing was something very rare on the DS). Same applies if you font turns out to be an image.
I hope nothing is compressed- compression it not half the issue it is on earlier systems. Again crystaltile2 has some support and most compression is fairly standard (to the point we have tools like http://code.google.com/p/dsdecmp/ ). Equally I hope no text is contained within the binary (the rom is one thing but there are sections- arm9.bin arm7.bin and the overlays that are loaded into memory that contain the games code and often some other stuff as well) so if remember pointers they are even more fun in the binary as you are addressing them directly in memory and probably finding a way to get some space.
Similar threads
