Previous: Parsing, Up: Top



5 Output

Each verb should have localized strings which are used to output results in whatever languages it accepts input in. In some languages, the strings will be blank (because they represent things not necessary in than language in that case). For example, open might output:

PRE_VERB + VERB + POST_VERB + ARG1 + POST_ARG1

In both english and lojban, the PRE_VERB will be the user's (localized) name. VERB will be the localized verb name. However, for both of them, POST_VERB will be empty.

The localized strings are stored by keys (which are Oz atoms) in the LanguageStrings object. Each database has only one such object. It is of the LanguageStrings class. Strings are stored using the setLanguageString method; see the Programmer's Guide for more details.

5.1 Localized String Contents

Each localized string key looks up a record. The record contains a language code label for each known language. The label points to the appropriate content in that language. Example:

     string(
     	en: "[unknown; timeout occured]"
     	jbo: "to na djuno ni'i le nu dukse le ni denpa toi"
           )

The only special case is that some languages do unusual things when a word is the first word in a sentence. These sentence-initial productions are handled by appending "SI" after the language tag:

     key: indefiniteVowelArticle string: string(
         en: "an "
         enSI: "An "
         lb: "le "
     )

5.2 Special Strings

Certain strings are rather more important than others, because they have low-level functions, such as handling article issues and capitalization.

There needs to be a string named <language>Name for each known language, with the full name for that language in all known languages as the values.

The key listSeperator1 stores the equivalent of the English comma, for lists of things. The key newlineString stores the localized newline character.

The following are used for articles: