This was taken from the Design doc, and needs editing and stuff.
Localization is the proccess of converting a particular program to work with a given language. Localization is rather important to the MOZ project as it was originally concieved as a way for me to write a mud that responded to commands in lojban (see http://www.lojban.org/), but I don't want to leave out the ability for MOZ to work in English or any other language.
Note that all localizations in MOZ use standard 2 letter codes where available, and made-up 2 letter codes where not.
The way that localization is normally handled, as far as I'm aware, is to have a big file somewhere that contains the text of all the messages that the program ever outputs to users. This is very impratical in something that grows with user programming the way MOZ does. Instead, the way I have decided to handle it is to have all the information for all supported languages stored on every object.
There are basically three issues that need to be dealt with for localization: parsing, verbs, and output strings.
Parsing is, unavoidably, going to be different across different languages. The way that this gets handled is to have different parser classes for each language, and to have the command line argument that sets the language have the effect of telling the Server which of those classes to use for the Parser object it associates with each player connection.
Verbs are the various commands associated with any given object. Essentially, verbs are a way of translating between what a player types (i.e. "get chair") and an Oz method (probably, eventually, the 'get' method on the 'chair' object). The names of the verbs are going to be different across different languages ('get' is 'cpacu' in lojban) as are the parts of speech ('chair' is the 'direct object' in English, but the 'second sumti' in lojban). However, all the different languages' ways of saying "get chair" are going to map to the same method on the same object (one hopes). So, each object has seperate lists of verbs for each language, but those lists should all essentially be doing the same thing.
Sooner or later, strings need to be output to the user. The way localization of arbitrary strings is handled in MOZ is to have the strings stored as Oz records named string with one different field for each language (using the two letter codes). Which string out of the list to pick is handled by a substitution method on the Connection object which also handles substitution of codes that represent the player's name and such.
Note that this system allows for different people on the MOZ to be using different languages to interface to the MOZ.
Also, storing verbs and localized strings as attributes allows the possibility of writing a piece of code that writes a file with Oz code in it that shows every localized piece of information currently in the MOZ. This can then be added to with a new language's information and then executed.