I came across a Japanese indie game I liked so I figured I'd try my hand at translating it.  I've finally managed to get an insertion script written and working, unfortunately much of my translations are too big to fit in the game's UI elements, and end up overflowing off the side.  Even worse, some strings have little to no padding giving me a hard limit of around 15 characters to write what should be 26.

Are there any special tricks to dealing with limited UI space other than just abbreviating things?  And for the limited length strings, is there some decompiler that can add padding to an executable without misaligning everything and invalidating pointers?

I'm probably asking for impossible things, but I figured if they existed, people here would probably know.

I reckon the possibilities include rearranging the UI or finding some way to hack whatever routine adds the text to the UI.  (In particular, are you still using fixed-width Shift-JIS?)

If you want to avoid misaligning everything, it stands to reason that the best way would be to find the pointer to the text you want to change, and instead direct that pointer to a space at the end of the file.

Well, if you can find the font and identify its pixel-format, then instead of inserting new text, the brute-force way of doing it would be replacing the characters with parts of the word you want to insert.  (That is, if you wanted to insert the word "TEXT", you could replace one Japanese character with "TE" and another one with "XT".)

Of course, if there's a gigantic script that's supposed to go into this UI, then this would involve identifying all suitable character pairs in the text and sticking them into the font, possibly expanding the font in the process – but in the case of a Windows executable, you don't have to deal with the same restrictions as a console ROM, at least.

You have a ton of options when it comes to PC game hacking.  It just depends on your skill level.  You can do anything from repointering the text to hacking in a DLL reference and rewriting the string-grabbing routine to grab from an external text file instead.

I'd set a breakpoint on the text string to be printed first and the printing routine should be nearby.  I'd read up some on how you can print text using DirectX.  At a minimum, it involves creating a new texture (dimensions based on string size) and copying characters from a preloaded font texture.  Then rendering to screen (may be relevant if you need to reposition).  There are some simplified functions in the D3DX library that may be used too.  Such as using ID3DXFont but I think that's unlikely because it's just a bitmap file.  It's probably the first scenario.