Transliterations

Transliterations are a special type of parallel text. In that sense, a manual transliteration can be handled in the same way as a translation.

Manual transliterations, however, are discouraged, for the following reasons:
 * There is more than one way to transliterate a work, and we want to be able to support as many transliteration styles as possible.
 * Any edition of the siddur should have consistent transliterations throughout the text, instructions, and commentaries.
 * We have a computer program that transliterates Hebrew text automatically.

When short blocks of transliteration are required in instructions or commentaries, the automated transliterator can be called using the j:segGen tag. The @type attribute is required on j:segGen; for transliterations, it has the value "transliteration". This tag is intended to be an analogue to tei:divGen for inline texts.

For example: indicates that an in-place transliteration of the Hebrew word is desired. As always, @xml:lang can be inherited from the j:segGen's ancestor nodes.

A processor should display some text related to the j:segGen, even if transliteration is turned off. Each processor may define its own fallback. Examples of fallbacks include: The formatting of the transliteration is handled entirely by the stylesheet.
 * Displaying the untransliterated Hebrew text.
 * Choosing a default transliteration table.
 * Flagging an error to the user (discouraged, but conformant).

In fully transliterated texts, the texts may be aligned at the discretion of the processor or stylesheet. They may conveniently be aligned at the same points at translation alignments when the text is both translated and transliterated.

=The Automated Transliterator=

For detailed technical information about the automated transliterator, see the XSLT 2.0 source code. The remainder of this file concerns the implementation details of the automated transliterator. The use of this particular implementation is not required by the JLPTEI guidelines.

The automated transliterator defines its own microformat, in the XML namespace (http://jewishliturgy.org/ns/tr/1.0). A RELAX-NG and Schematron schema for the format is provided in the source code. A transliteration schema is a pluggable component that is used to define the correspondence between a Hebrew alphabet form and a form in another alphabet. In addition, transliteration schemas may be used to transliterate between any other alphabets and script systems.

An example table (SBL transliteration style) is reproduced below:

The tr:schema element is the root of a transliteration schema. It contains at least two required descriptive elements, tr:title and tr:description. Both descriptive elements are required to specify the language of the description using @xml:lang attributes. The description and title may be translated into other languages as well, using additional sibling tr:title and tr:description elements.

The schema then contains one or more tr:table elements.

The tr:table element contains one or more tr:lang elements, followed by one or more tr:tr elements.

The tr:lang element describes the table's input and output language codes. The @in attribute is used to determine which table should be used to transliterate at any point in a text. Therefore, the value of the @in must be unique within the schema. The @out attribute indicates what language code should be used for the output. For example, if @in="he", and the transliteration is into Latin script, @out="he-Latn"

Each tr:tr element a single @from attribute and a single @to attribute. Some composite characters (eg, &hiriq;&yod;) are treated differently from the sequence of characters &hiriq; followed by &yod;. All of those cases are shown in the example above.

Note that the dagesh may result in a different transliteration of a letter in all cases, except vav, where vav followed by dagesh in the transliteration table indicates a shuruq. The transliterator doubles dagesh hazak, but @from does not otherwise distinguish between dagesh hazak and dagesh kal. Virtual doubling can be disabled by adding a @double="no" attribute to the transliteration entry.

A shin with no shin-dot or sin-dot in @from represents the "silent sin", seen in "Issachar."

By default, the transliterator ignores silent vowel letters (eg, aleph, he). Some transliteration styles require these letters to be displayed in transliteration. In those cases, use an attribute @silent in addition to @to, to indicate how the silent letter should be transliterated.

The XML entities corresponding to Hebrew letters are in the source file hebrew.ent. Their use is not necessary, but helps for the display of some characters.

The transliterator also supports some options. These options are placed in tr:option elements, each of which has an @name and @value (both of which are case-sensitive). Supported options and values are shown below:

=Testing Transliterations=

THIS SECTION IS WRONG!

For testing convenience, the standard "make" done in trunk will build a test file called /text/strongs/strongs-xlit.xml. This file contains all of the 8,674 unique Hebrew/Aramaic words found in the Tanach. It can be used to test transliteration styles in order to ensure correctness of the transliteration tables. In order to run a test, change the following line (at line# 54 in the strongs-xlit.xml file) in the file so that it specifies the correct transliteration table to use:

Valid transliteration table values are:
 * strongs = Strongs Concordance style
 * sbl = Society of Biblical Literature style
 * mih = Modern Israeli Hebrew style

Once the transliteration style has been set in strongs-xlit.xml, run the following shell command (in the following example, the command is run from the trunk directory):

The resulting strongs-xlit.html file can be then browsed to verify the correctness of the transliterations. The basic format of each entry is:

which is:

where:

The words are all listed on the first line in alphabetical order with their associated Strong's Concordance number for easy reference and pronunciation (to help those who don't read Hebrew well). On the second line, the generated transliteration is listed. Whenever a new transliteration style is defined, this file should be used to help verify the correctness of the transliterations.

Alternatively, if the tester only wants to test the effectiveness of the transliteration against a limited section of text, a custom transliteration xml file can be created. Note: the same considerations regarding setting the transliteration style and running the transform.sh command would apply for custom xml transliteration files.

Here is an example custom transliteration file which outputs a line of Hebrew text followed by the transliteration of that line (using the SBL's transliteration style):

Here are the first few lines of output from this custom transliteration file: