kaz
This is the technical description of a DBT Translation table. If you want more general information about languages and template choices, please see the list of templates.
Initially, the language table for braille translation is determined by the selected template, and may be changed using the Document / Translation Tables menu. Using those menus does not require use of the table designator. However, to switch to a different translation table partway through a file, one must enter a DBT code and the designator for the table to switch to. For switching secondary languages within a base language table, see the [lng~X] command. For switching from one base language to another, see the [lnb~...] command.
The Kazakh Uncontracted tables support print-to-braille translation of Kazakh-language literary text written in the Cyrillic alphabet. They are intended primarily for use in conjunction with Microsoft Word, or equivalent external facilities for composing and editing the print text that can then be imported into the Duxbury Braille Translator (DBT) for conversion into braille. English text may also be processed as a sub-language, and converted to contracted or uncontracted English braille (generally following British conventions in those minor instances where they differ from American ones). French, Bulgarian, Russian and Ukrainian may also be processed as sub-languages.
Automatic hyphenation of the braille (that is, automatic introduction of assisted-hyphenation codes during the translation to braille) is supported by default, though it can be turned on and off by translation codes.
Braille-to-print translation is supported for this language. However, braille-to-print translation may not be perfect, therefore beware that errors can occur. If you find errors or have suggestions, please send both the *.dxb and *.dxp files along with an explanation to: languages@duxsys.com. Please be sure to include sample files!
Even though DBT from version 10.5 onward can display Cyrillic and Arabic characters, it is usually more convenient to use an external word processor to compose and edit the print text that is to be translated. When doing so, is necessary to use a facility that encodes the text in Unicode so that it can be imported correctly to DBT. (Some methods of entering Cyrillic rely upon a variant "font" to display standard ASCII characters as Cyrillic. Those methods cannot be used, as those ASCII characters would be imported according to their standard interpretation, not as Cyrillic characters.)
Microsoft Word, properly used, fulfills the above requirements. Use the Lucida Sans Unicode font, or equivalent Unicode font, and a Kazakh (or Cyrillic or Arabic) keyboard, when entering the Kazakh text.
English text may be entered as a secondary language, and converted to uncontracted English braille.
French language text may be entered; it is brailled as uncontracted French braille, including the dots 46 capital indicator.
Bulgarian, Russian and Ukrainian language may also be entered; they are brailled in the same way as Kazakh.
Note that in addition to the above-listed "secondary languages" supported within the Kazakh table itself, it is also possible to switch to any of the available translation tables listed in DBT. (See the [lnb~...] code below.)
No technical codes are supported.
However, it is possible to switch to any of the available translation tables listed in DBT (see the [lnb~...]code below), many of which do support various technical codes, such as for mathematics or computer notation, or which support “unified” treatment of technical notation as well as literary text in the base language associated with the table.
The following DBT translation codes are available when using the Kazakh table. Any other translation codes used will be ignored, or indeed may cause unexpected results. If using an alternative translation table, i.e when switching to another base language table by means of the[lnb~...] code, please refer to the relevant topic and available codes for that table.
[/] may be embedded within letter-groups that would normally be contracted, to prevent the contraction.
[ab] is equivalent to [g2]
[ahy] or [ahy1]turns on automatic hyphenation of the braille (which is initial and default condition)
[ah0]turns off automatic hyphenation of the braille
[fte~b]
[fte~i]
[fte~u]
[fts~b]
[fts~i]
[fts~u]
[cz]
[g1] switches to "grade 1" (uncontracted) braille. This does not have any effect in this table, as all braille is uncontracted anyway.
[g2] switches to "grade 2" (contracted) braille. This is the normal mode, but actually has no effect as Kazakh and all secondary languages are are always transcribed uncontracted.
[in] is equivalent to [g1]
[lnb]
[lnb~...] (for switching to another base [primary] language table)
[lng~bg] switches to Bulgarian language.
[lng~en] switches to English language.
[lng~fr] switches to French language.
[lng~kk] or [lng] switches to Kazakh language.
[lng~ru] switches to Russian language.
[lng~uk] switches to Ukrainian language.
[tx] resumes normal translation, ending "direct braille."
[vrn] cancels [vrn~spc], restoring the normal suppression of spaces after commas and semicolons.
[vrn~spc]preserves the spaces following commas and semicolons, which by default are removed in Kazakh braille.
The table is designed to work with the following groups of characters:
All ASCII printable characters
Accented characters and punctuation marks typical of French, German, Italian, and Spanish
British pound sign (£)
Cyrillic unaccented and/or Arabic characters as needed for the supported languages.
The above is a general guide only (see "General Notes" section at the beginning of this document).
These tables were originally based upon the information given for Russian, Kazakh and the other supported languages in "World Braille Usage," a joint publication of UNESCO and the National Library Service for the Blind and Physically Handicapped, Washington, D.C. (1990). According to that publication, contractions are not used in Kazakh braille and so these tables should produce braille that is normal for that country.
The tables were originally developed in June 2000 by Duxbury Systems, Inc. We are indebted to Oleg Shevkun and J H Fernandez Garza for more recent information that has been used in their maintenance.
(Documentation reviewed: July 2010)