Bug Tracker – Bug 186

Internationalisation

Last modified: 2014-03-20 00:24:00 CDT
Bug 186 - (ARRAY(0x5e29fa0)) Internationalisation
(ARRAY(0x5e29fa0))
Internationalisation
Status: NEW
Product: Odamex
Classification: Unclassified
Component: Server & Client
(old) 0.0.1
All All
: P5 enhancement
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-04-02 15:26:27 CDT by Denis Lukianov
Modified: 2014-03-20 00:24 CDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Lukianov 2006-04-02 15:26:27 CDT
Need a volunteer to organise the tranlsation effort. All menus, console text, etc. You do not need to know lots of languages, just lead the effort. Set up a status page on the wiki and find people to translate. Keep organised lists of strings. When there's at least one complete-ish language, we'll integrate it into the source.
Comment 1 Alexander Mayfield 2006-04-04 10:43:46 CDT
Are you planning on abstracting all languages out into loadable language files, or hardcoding multiple languages in the source?  I think the former would be easier in the long run.

And that said, czech and russian support would be awesome.  But this brings up something else, how will we deal with languages that require an entirely new charactor set or accents?
Comment 2 Denis Lukianov 2006-04-04 11:02:08 CDT
(In reply to comment #1)
> Are you planning on abstracting all languages out into loadable language files,
> or hardcoding multiple languages in the source?  I think the former would be
> easier in the long run.
Yup, the former

> And that said, czech and russian support would be awesome.  But this brings up
> something else, how will we deal with languages that require an entirely new
> charactor set or accents?
Unicode support is one possibility. And yes, I know that will be very tough to do.
Comment 3 Denis Lukianov 2006-04-07 11:45:41 CDT
A lot of French strings can be found in d_french.h in linuxdoom 
Comment 4 GhostlyDeath 2008-06-08 20:08:12 CDT
FOR THE SOURCE CODE:

I could throw down some groundwork if needed. We can either switch to unicode or use multi-byte.

 * Unicode *
   - Supported by Windows NT
   - Windows 98 requires unicows
   - More overhead to convert everything to unicode and knowledge of character 
sets to convert 
   - Most linuxes support unicode
   - Don't know about mac or other OSes
   - support for older clients not understanding unicode (Out of date version, etc.)
 * Multi-byte *
   - Existing strings can be supported, a special character to determine whether something is multi-byte or not can be placed and and the correct graphics can be loaded.
   - Foreign characters will probably always be multibyted

For both of these, windows supports printing unicode characters as long as it's a unicode console and windows has multi-byte to unicode and vice versa. Linux can print multi-byte characters as long as the correct locale is set.

For both, it may be possible to have client language set and a server defualt language set, that is...

*** SERVER CONSOLE ***
[01:23:45] GhostlyDeath se ha conectado.

*** CLIENT CONSOLE ***
GhostlyDeath has connected.

Then in this case if you join a server and the server sends you messages in your local language instead of the servers.