[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Temporarily mapping non-ascii->ascii characters in gettext

Well, at some point we should decide what to do with this kind of games, and this moment is as good as any other. The real problem is that in many games characters are printed in screen using sprites, that means, graphical images representing the characters, instead of real fonts such as ttf or bdf.

Game developers usually only take into account their own language when developing this graphical images of characters, which means only ASCII and parts of ISO are implemented, and not always even the full sets of them. This affects french, of course, but also Spanish, so it's something that interests me at all. Of course, greek or cirillic character sets, or japanese, vietnamese and so, are not even rempotely supported. Game developers don't usually consider the character set at any point, so no unicode or utf8 support is usually found.

Translating those games into languages that use a different character set than ASCII, and probably some ANSI characters in some cases, will often require drawing new sprites with the representation of the new letters. Sometimes even artistic representations, rendered in 3D, or painted with colours and so, are done, so to implement new characters some artistic work needs to be done. Upstream often won't consider doing it themselves.

Any idea on how to handle this kind of games? At least a mapping to ASCII characters is a doable way. Maybe modifying the game so that ttf fonts could be handler could be a way, but it might be quite costly to do that for more than just a couple of games, and it'll probably imply severe patching and diverging from upstream too much. There's no way we can get such cute hand-drawed or 3D rendered fonts with ttf, so the game would end up being a bit poorer.


Reply to: