Difference between revisions of "Multilingual Support"
(→The Idea) |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == The Idea == | |
| − | + | This is an idea that [[User:Voxel|Denis]] came up with (and so did [[User:Manc|Manc]]! I'm not getting sole blame for this! -- [[User:Voxel|Voxel]]). This would obviously be a long way off, like perhaps 1 or 2 years, and would be relatively low priority, but would be really neat to have. | |
| + | Here is a design document for implimentation. This is by no means final, and is an attempt by the [[User:AlexMax|author]] to jot a few ideas down on internet paper. | ||
| + | |||
| + | == The Road to Implementation == | ||
| + | |||
| + | === Modularisation === | ||
At a very basic level, this would require abstracting and extension out two things, the font system (for the console/top message), and the graphics system (for status bar, menu). | At a very basic level, this would require abstracting and extension out two things, the font system (for the console/top message), and the graphics system (for status bar, menu). | ||
| − | I propose that the different languages would be kept in a special WAD file. This WAD file would contain the replacement graphics for the status bar and menu, and also contain a few text lumps with the replacement text in it. This would be a stickler as no known wad lump editor that I know of has unicode capabilites, but that could happen...in time. | + | === Storage === |
| + | I propose that the different languages would be kept in a special WAD file. This WAD file would contain the replacement graphics for the status bar and menu, and also contain a few text lumps with the replacement text in it. This would be a stickler as no known wad lump editor that I know of has unicode capabilites, but that could happen...in time. (wads contain raw lumps, so adding that functionality should be trivial) | ||
At runtime, you would load the language WAD of your choice, and it would load (and replace) all of the graphics, and then interpert the text as well. Obviously a failsafe for english would be nice in the absence of any language WAD. | At runtime, you would load the language WAD of your choice, and it would load (and replace) all of the graphics, and then interpert the text as well. Obviously a failsafe for english would be nice in the absence of any language WAD. | ||
| − | Obviously, loading a 'different' client file than the server on purpose could open up a whole new range of exploits, so special care would need to be taken with this implmentation. | + | === Potential problems === |
| + | Obviously, loading a 'different' client file than the server on purpose could open up a whole new range of exploits (it would? -- [[User:Voxel|Voxel]]), so special care would need to be taken with this implmentation. | ||
| − | Also, in order to | + | Also, in order to incorporate extended characters in the console and message text, you would have to modify the font system and also make unicode fonts that look 'doomy'. No easy task, and it might be a prudent idea to ditch CONSFONT and just draw the console font with doomy text, like Eternity does. |
| + | === Things that should remain untouched === | ||
However, you wouldn't actually want to modify or translate any console specific things (like set, the names of variables, console error messages, etc.). To me, the console specific commands are like a programming language, you don't have multiple versions of C++ for multiple lanaguages, do you. :) | However, you wouldn't actually want to modify or translate any console specific things (like set, the names of variables, console error messages, etc.). To me, the console specific commands are like a programming language, you don't have multiple versions of C++ for multiple lanaguages, do you. :) | ||
| + | |||
| + | == The Implementation == | ||
| + | |||
| + | {{Bug|186}} tracks this issue | ||
Latest revision as of 16:43, 4 April 2006
Contents
The Idea
This is an idea that Denis came up with (and so did Manc! I'm not getting sole blame for this! -- Voxel). This would obviously be a long way off, like perhaps 1 or 2 years, and would be relatively low priority, but would be really neat to have.
Here is a design document for implimentation. This is by no means final, and is an attempt by the author to jot a few ideas down on internet paper.
The Road to Implementation
Modularisation
At a very basic level, this would require abstracting and extension out two things, the font system (for the console/top message), and the graphics system (for status bar, menu).
Storage
I propose that the different languages would be kept in a special WAD file. This WAD file would contain the replacement graphics for the status bar and menu, and also contain a few text lumps with the replacement text in it. This would be a stickler as no known wad lump editor that I know of has unicode capabilites, but that could happen...in time. (wads contain raw lumps, so adding that functionality should be trivial)
At runtime, you would load the language WAD of your choice, and it would load (and replace) all of the graphics, and then interpert the text as well. Obviously a failsafe for english would be nice in the absence of any language WAD.
Potential problems
Obviously, loading a 'different' client file than the server on purpose could open up a whole new range of exploits (it would? -- Voxel), so special care would need to be taken with this implmentation.
Also, in order to incorporate extended characters in the console and message text, you would have to modify the font system and also make unicode fonts that look 'doomy'. No easy task, and it might be a prudent idea to ditch CONSFONT and just draw the console font with doomy text, like Eternity does.
Things that should remain untouched
However, you wouldn't actually want to modify or translate any console specific things (like set, the names of variables, console error messages, etc.). To me, the console specific commands are like a programming language, you don't have multiple versions of C++ for multiple lanaguages, do you. :)
The Implementation
Bug 186 tracks this issue