Sentence Basics

GlobalConcat System Localizer (aka “System Localizer”) divides system input into the following areas:

1. Text only. This is straight text, perhaps with artistic layout information included, which text is transferred from a database to a System Localizer extract file. Then, the Runtime Engine calls the extract file and transfers that text and its attributes to another destination, such as website, kiosk, ATM screen, etc.

2. Visual only or visual and text. Visual implies images or multimedia arranged in a manner that is pleasing to a user, and which images can be exchanged and re-arranged without changing the product code.

3. Concatenated text or voice prompts. Whenever dates, times, numbers, names or multiple-choice prompts are inserted at runtime, System Localizer provides the environment for highest grammatical results in all languages, without reprogramming on a language-by-language basis. This use of System Localizer impacts voice applications such as telephony in all its variations.

FOR APPLICATIONS:

From the point of view of applications such as IVR with text and audio (with and without associated web text appearance), the System Localizer System Localizer provides, among others, the following:

Data storage – either in whole or in part, with “part” generally meaning concatenated sentence prompts and text. Many applications involve high numbers of international languages, many of which are 2-byte or right-to-left character types, and that often make those responsible uneasy and insecure. System Localizer handles and stores all such languages. System Localizer creates and imports scripts to and from translators in a hands-free environment, creates translation and concatenation verification reports, plus produces database content reports and scripts for both the developer and the voice talents.

Globalization – of the client’s system to assure that will function across the language spectrum without further code changes once the initial preparation has been performed. Systems developed from the ground up using System Localizer will never require reprogramming, tweaking or alteration related to other languages or dialects, nor for customer-specific exceptions, as long as recommendations of a System Localizer professional are followed on all levels.

Combining globalization and data storage involves readjustment to the planning and approach to application sentence structures. With System Localizer, many preconceptions have been broken, and automatic reactions of programmers circumvented. System Localizer makes several changes to the basic principles of programming that affect language-localized applications, because there were a number of errors in the university-taught approach to the use of prompts and variables for variable information related to linguistic issues. Those weakness have been identified and rectified in System Localizer in order to make it possible to program an application once, yet have that application function in all languages without constant tweaking.

Handling full sentences in any environment is generally an easy issue. Thus, although System Localizer can handle straight text and full “normal” prompts and sentences of an application, this document concentrates on the area more difficult to localize – concatenated sentences and multiple choice of prompts.

WHAT IS A SENTENCE?

In order to resolve the inherent conflict between one language sentence structure and another, and then to marry that solution to the logical processes of computer language, “sentences” have been divided into categories.

There are two types of sentences in System Localizer :
1. Language sentence
2. Application sentence

LANGUAGE SENTENCE:

A “language sentence”, also called “full sentence”, means a grouping of words that must contain a subject and a verb, and must be followed by a period or exclamation mark or question mark.

In System Localizer, every unit must be a full sentence of some kind. And because every entry must be a full sentence (with or without variable information), and once this concept is clear, there need be no more talk of “language sentences” but only of “Application Sentences”, as explained in the next section.

The concept of a mandatory full “language sentence” for each entry is already a different approach than has been used in the past in any telephony system, and is not part of the accepted rules of programming for telephony applications.

Excellent and brilliantly programmed legacy systems are riddled with “non-full-sentences” that will not function when translated, such as:

“Received .”
…”deleted.”
“Transferring to…”

Such unfinished sentence techniques are learned from others, and are general practice. But this same approach also guarantees that no system will function when translated, without reprogramming or tweaking of data tables, language by language, line by line.

GLOBALIZING LANGUAGE SENTENCES:

Thus, the first step to assuring an excellent international application is to “globalize” the “language sentences”. Globalizing is the act of creating full, internationally acceptable grammar structures from previously unfinished phrases in such a way that will translate properly, and play in highest grammar in the original language as well as all future languages.

All “language sentences” must contain one single variety of each of grammatical part:

One – Subject (mandatory)
One – verb (mandatory)
One – direct object (if any)
One – indirect object (if any)
One – adverb (if any)

According to learned and programming techniques as currently practiced, any one of the above items could be used as a variable, to be altered or replaced at will via hard code or data tables. Thus, developers have created sentences with no subject, or no verb, and tacked on other unfinished sentences willy-nilly. Globalizing the system means turning such uncontrolled concatenations into organized sentences and lists, with either one subject, one verb, and one variable (or one of each of the remaining three types, if desired), or, if more than one subject or verb is desired, laying out those sentences or lists in an internationally-compatible manner.

Another important issue is the separation of names (representing humans or mammals) from things (such as mailboxes, lines, digits). In programming, “people” have been treated as “objects”, and swapped freely one for the other via code, which also does not function when translated.

Thus, in globalizing a legacy system, or in creating a new system using System Localizer System Localizer, developers can say anything they wish to say – in fact, they have much more freedom than every before! – but the way that the information is entered and stored will be vastly different from previous training and experience.

Using again the above original examples of unfinished sentences, below are the “finished” examples, bearing in mind the need for one subject-verb-object per sentences, and separation of people from objects:

PREVIOUS:
“Received .”
…”deleted.”
“Transferring to…”

GLOBALIZED TO:
“(fax) received .”
“(message) received .”
“(email) received .”

“(fax) deleted.”
“(message) deleted.”
“(email) deleted.”

“Transferring to…”
“Transferring to…< number>”

The words in parentheses, such as fax, message, email generally do not appear in the translation or a recorded voice prompt, but the mandatory subject (fax, message, email) assures that the proper word “received” will appear in all translations. There can be up to 12 different versions of “received” varying with the “sex” of the object received and the number of objects.

The process of globalizing a system will often cause the need for other determinations to be made, especially for legacy systems. Legacy systems often do not differentiate between “people” and “objects. Or, do not differentiate between which object was received, such as whether fax, email or voicemail was received. Thus, these considerations and changes alone cause incorporation of differentiation into code and planning

APPLICATION SENTENCE:

Once the “language sentences” above have been properly globalized, there need be no further discussion of their content as a sentence – because everything has become a “language sentence”, thus the discussion moves to the coding practices and “call up” of the units created during the globalization process, called “application sentences”.

The name “application sentence” or just “sentence” arises from taking one original “unfinished sentence” and creating multiple children – new sentences that are variations on a legacy sentence:

One:
“Transferring to…”

Became two:
“Transferring to…”
“Transferring to…< number>”

However, from a coding point of view, these actions occur at the exact same point in the code. Thus, System Localizer refers to the new unit as a “sentence”, even thought is has a choice of two parts.

Thus, for lack of a better word, an “application sentence” is actually a unit – meaning one sentence or multiple choice of sentences – under the umbrella of a single name, with one thing in common – one, several or all of their list will be called at the same time in a location in the product code.

Thus, the System Localizer naming and references tend to change a previous client “prompt” name, to a “sentence” name, with that sentence name referring to a larger scale collection of prompts and variables:

Original client prompt/sentence:

AUD_TRANSFERING_TO or
“Transferring to…”

Globalized to:

CV_TRANSFER
[0] “Transferring to…”
[1] “Transferring to…< number>”

This sentence called “CV_TRANSFER” is incorporated into the client’s code. At runtime, the client code will provide System Localizer with information as to whether is name or number, and System Localizer will tell the system what audio files to play. For many legacy apps, the distinction between people and numbers is new, but must be handled to assure a good international application. More about sentence names and actions on next page, and more about variable names later.

SENTENCE NAMING CONVENTIONS:

As of this point in the document, the topic is “application sentences”, so assume that references to “sentence” refer to the unit, which may be a single entity or may be a list of multiple-choice sentences from which to choose under any single umbrella name. a single entity might be “Thank you for calling ABC company.” or “You have messages”. Multiple-choice may be a “sentence” called “PressX”, from which the client’s application may request “Press_1”, “Press_2”, “Press_9” and so on.

A naming convention has been created by System Localizer that provides some logical hints and guides to the developers in organizing their own code to call up those sentences. There are prefixes that have meaning to the Runtime Engine. When the developer begins to code, the naming convention may also be of help in avoiding errors and discrepancies.

The way System Localizer “thinks” is different than previous experience. Thus, once the categories of application sentences are understood, units falling under the various categories must have names with proper prefix according to their category, as a memory aid and to facilitate correct coding and reading by the Runtime Engine.

One of the only ways to seriously damage system playback is to fail to include the proper prefix to a sentence name.

CS – COMPLETE OR CONCATENATED SENTENCE

The word “concatenated” has broad uses, of course, and “concatenated sentence” could mean that this sentence is concatenated to a previous sentence, or that this sentence is comprised of multiple parts concatenated together to form a whole, or even text to speech with sounds concatenated to make a single word.

“CS”, in System Localizer terms, indicates anything that will always play when called. Examples:

CS_WELCOME
Welcome! Thank you for calling ABC Bank.

CS_WELCOME
Welcome! Thank you for calling ABC Bank. For account balance information
, for personal assistance
.

When CS_WELCOME is requested, if it is available in the language chosen, it will always play, no matter what. If it is not available in that language, it will never play. (The language assignment is one way of selectively playing or not playing sentences).

In the first case, there is no variable information. In the second case, there are two variables, the content of which can be assigned via the GUI and extract to play:

CS_WELCOME
Welcome! Thank you for calling ABC Bank. For account balance information
, for personal assistance
.

With System Localizer, the application can play different numbers to press for another bank, or for that same bank outside of office hours. Meaning, information is versatile, and can be changed long after the application is compiled and deployed.

The use of the letters “CS_” is mandatory. Is not optional. The mere fact that the “CS_” precedes the sentence name indicates that no numeric criteria are necessary to decide which version of that “application sentence” to launch.

PL – PLURAL and PLCCAT (Plural Copycat)

The word “plural” immediately brings to mind a singular, and – in a programmer’s eye – also a “zero” of something..

The “PL” prefix indicates that the sub-component to play (sub-sentence) is determined by the of that object returned at runtime. Examples:

PL_EMAILSRECD
[0] You have no email.
[1] You have one email.
[2+] You have emails.

Where:
numberBefNoun = “number that is played before a noun and modifies that noun”.

Which selection (0,1,2+) to play is determined by the value of . Thus, < numberBefNou#1> is called the “defining variable”, because it makes the determination on the fly which component to select.

In an “inventory” atmosphere, there may be a long list of possible items, each of which can vary by number received.

PL_EMAILSRECD
[ST=0] You have no mail. (“ST” = Sum Total)
[1+] You have : (or “In your mailbox:“ )
[1] one message. (defining var #1)
[2+] messages.
[1] one fax. (defining var #2)
[2+] faxes.
[1] one email. (defining var #3)
[2+] emails.

There are 3 numbers (#1,#2,#3), passed in that order to the Runtime Engine. The Runtime Engine will select which component to play according to the numeric value provided. “You have no mail” will play if the sum total of #1, #2 and #3 = 0. The #1, #2, #3 are called the “defining variables”, and each sub-sentence will have its own defining variable, except the total=0 component. There is a feature in the System Localizer GUI that stores the defining variable in relation to each component. And the defining variable numbers are included in the Extract for computations by the Runtime Engine during its decision-making.

Note the that “+” is “inclusive”.

PL sentences cannot be hard coded. They must be fluid. The client’s code will simply pass the values to the Runtime Engine. The reason the above cannot be hard coded, is that many languages may have entirely different PL components. Examples:

MANDARIN

PL_EMAILSRECD
[ST=0] You have no mail. (“ST” = Sum Total)
[1+] You have : (or “In your mailbox:“ )
[1+] message.
[1+] fax.
[1+] email.

ARABIC

PL_EMAILSRECD
[ST=0] You have no mail. (“ST” = Sum Total)
[1+] You have : (or “In your mailbox:“ )
[1] one message.
[2] messages.
[3-10] messages.
[11-99] messages.
[1] one fax.
[2] faxes.
[3-10] faxes.
[11-99] faxes.
[1] one email.
[2] emails.
[3-10] emails.
[11-99] emails.

ABOUT “PEOPLE PLURALS”:

In the past, “people” have been treated as “objects”, and swapped freely one for the other via code. However, “person” must be separated from “people”, with the word “people” being plural. Thus, any sentence that could result at one instance with one person being mentioned, and another instance with several people being mentioned, must be handled as a plural. Example:

PL_MESSAGEHEARD
[0] Message has not been heard by recipients.
[1] Message has been heard by
[2] Message has been heard by”

or

PL_MESSAGEHEARD
[0] Message has not been heard by recipients.
[1] Message has been heard by < list of names > (results in playing one name)
[2] Message has been heard by” < list of names > (results in playing more than 1 name)

The use of the letters “PL_” is mandatory. The fact that a “PL_” precedes the sentence name indicates to a developer that at least one numeric runtime (not hard coded) value must be passed to make the sentence function.

Also, in most legacy applications, developers have never distinguished between whether 1 result will occur or several. The Runtime Engine relieves that responsibility.

CV – CRITERIA VARIABLE

A Criteria Variable began as the concept of multiple choice, and then narrowed to not only a list of multiple choice options, but also to include one single choice, as long as the “choice” is made via a numeric value provided by the system for the sole purpose of choosing which entry or entries (or no entries at all) to initiate. Which multiple choice entry to select must be organized, and coded, by the developer in some manner, because the numeric variable based upon which the selection is made does not appear in any component of the sentence, as it did with PL-Plural sentences.

So, a “CV” is a criteria variable-selected sentence with one or more components, any of which – or none of which – may play according to the numeric value passed by the application while it is operating. Each component in the CV multiple choice list will be selected through use of the same selection number whose value is set by the developer in own manner. If only certain components in the CV list are to be selected based upon a criteria number, and other components will either always play (if so organized) or be selected using a different defining number.

There are two types of CV sentences:

1. Client CVs
2. System Localizer Software CVs

CLIENT CV’S

Client CVs are CV type sentences that apply only to the client’s application – rather than being for use across every developer’s application in the industry. Example:

CV_TRANSFER
[0] Transferring to operator.
[1] Transferring to .
[2] Transferring to .

(almost unlimited rows/components permitted)

Which selection to play is determined by the value of phantom variable , which does not appear in the list. is generated by the developer’s code and passed to the Runtime Engine at runtime. Thus, the variable “” becomes the second variable , with the first being the phantom “” provided as criteria variable for component selection. And “” becomes variable #3 for the same reason.

The “CV” concept is quite useful for other circumstances. A “CV” can also be used as variable information for insertion into another sentence unit. Because a CV sentences are entered properly by System Localizer with each component as a full “language sentence”, the components of another CV can be called by, selected and played from another sentence. Example:

CLIENT CV #1:

CV_GETHELP
[0] Please see store manager.
[1] Please go to Customer Service Desk.
[2] Please ask a store associate for assistance.

CLEINT CV #2:

CS_SOLVEPROBLEM
“Barcode is unreadable. ”

To use a “sub-CV”, simply assure that each row component can stand alone, or is a list of some kind. (lists are discussed later)

NAMING A CV:

Use of the letters “CV” as the first two characters of the application sentence name is mandatory. Without the letters “CV”, the System Localizer GUI will not know to assign a phantom variable in the database or Extract, and the GUI would automatically falsely number the variable as , whereas it is actually variable #2.

One of the only ways to seriously damage system playback is to forget to include the letters “CV” at the beginning of a Criteria Variable sentence.

System Localizer SOFTWARE CV’S (also called “System Localizer CVs” or “software variables”)

Due to the principles of good practice of programming that actually make it impossible for a system to translate properly without code or data table twiddling, System Localizer has created certain CVs that force a developer to use components that are assured to work when translated. System Localizer also has various checks and balances to catch programming that uses variables that will not function, and to guide the developer in the right direction for international compatibility.

Any changing information that uses all or part of a date, time, number, language or press can only be used as a System Localizer CV. Permission to repeat — Any variable information that uses all or part of a date, time, number, language or press can only be used from a System Localizer CVs. No programmer should ever hard code or create Client CVs that contain:

• DOW (days of week)
• Month names
• Years
• Hour/minute elements
• Language names
• Press prompts

This also applies to all variations on the above, such as used with “from” “to” “for” “through” and other prepositions.

NEVER CREATE:

Office hours are through
System will be down on
Meeting changed to .
System set to
To access your mailbox press

Any sentence created by client that uses broken down pieces of dates, times, languages or press such as above must utilize the System Localizer Software CVs provided for this purpose. There is a “from date” and a “from DOW” and so on. All of the components are there for the developer to choose. If this rule is followed, the client’s system will play excellent grammar and have classy playback around the world with no code changes.

Examples of use of System Localizer CVs (software CVs):

CS_WORKHOURS
Office hours are

CS_SYSTEMDOWN
The system will be shut down

CS_CHOOSELANG

The System Localizer variable token names do not need to be memorized. In fact, no variable names need to be memorized. The System Localizer GUI provides a point-and-click variable selection method, with examples of usage for clarification, to make selecting the proper variable convenient and identifiable. Additionally, System Localizer reads the prompt content (text before and after each variable) during the import process looking for errors, discrepancies and incorrectly chosen variable names.

System Localizer CVs have fixed names. At first glance they appear to be longer than one would expect. And a bit weird. But that is because the naming convention both assures that multiple date types can be used in any application without confusing formats, and to assure that their audio files will not override each other. Also, the names of the prompts actually inform the programmer of the exact order in which each should be played. Not that the programmer needs to hard code the play order – System Localizer will do that – but it is nice to know that the names are actually readable and understandable even if their content is in a character language that the developer cannot read or understand.

VARIABLE TOKEN TYPES

The word “variable” or “variable token” in this sense is used fairly broadly, and refers to the name assigned to any information that may change on the fly at runtime. There are 5 types of variable tokens in System Localizer :

• Times
• Dates
• Numbers
• CVs (client and System Localizer CVs)
• Pass Thru

Times and Time CVs

All full times come in up to 3 different formats:

• 24 Hour (13:45)
• AmPm (1:45)
• Before Hour (quarter to 2)

Which formats are available will vary with the language selected. The “before hour” variety is actually dominant in several countries, so System Localizer makes it possible for companies to offer a variety of localized formats as never before. And because time is often spoken differently it is not modified by “at”, there is also an “is time” selection.

• 24 Hour with “at”
• 24 Hour (use with “is”)
• AmPm with “at”
• AmPm (use with “is”)
• Before Hour with “at”
• Before Hour (use with “is”)

Dates and Date CVs

Includes any and all variations on full dates, or date components. There are 12 basic variations on any one format for a date in any one language. Dates Formats must be defined as follows for each instance:

• With DOW with “on”
• With no DOW with “on”
• With DOW with Year with “on”
• With no DOW with Year with “on”
• From date with DOW
• From date no DOW
• From date with DOW with Year
• From date no DOW with Year
• To date with DOW
• To date no DOW
• To date with DOW with Year
• To date no DOW with Year
• With DOW (used with “is”)
• With no DOW (used with “is”)
• With DOW with Year (used with “is”)
• With no DOW with Year (used with “is”)

99% of all languages only have one format of the above. However, English offers the widest range of date formats, having 5 different date formats each of which has equally as many varieties according to the above list.

ENGLISH-ONLY DATE ENDINGS:

• July 2nd MDo (month, day, ordinal)
• July the 2nd MDto (month, day, “the” and ordinal)
• the 2nd of July DMo (day, month, ordinal)
• July 2 MDn (month, day, number)

For English only, in order to inform System Localizer exactly which date format you desire for a particular circumstance, the date ending is added to the date format. Example:

With no DOW with Year with “on” yields: on Jan 5th, 2005
From date with DOW yields: from Tuesday, January 5
With DOW (used with “is”) (today is) Sunday, Jan the 5th

From an economic perspective, if the application is for voice and thus includes recording voice prompts and audio files, the client may wish to save on the budget by choosing a limited number of date formats for the application. But the variety is there, enough to please the most discerning of clients.

Also, this variety allows for each country to select its preference. UK, for example, often prefers “the 2nd of “ variety, New Zealand “July the 2nd”, and the U.S. uses “July 2nd” or “July 2”.

The Date variables are translated including their relative prepositions (“on”, “from”, “through”). Then, the database is normalized, and one prompt entry compared to another, in order to avoid excessive repeated recordings. But many languages change their prepositions even within the same date where, for example, the word “on” may be different if were “on Sunday” than for “on Monday”. System Localizer handles these contingencies, and eliminates redundancy where possible, keeping in mind the need for a cohesive, grammatically correct result in all languages.

Numbers

Numbers actually have 4 different world number formats for 1 – 99, and 4 major different concatenation patterns over 99.

For 0 – 99 the number formats are:

• Number Telephone
• Number Stand Alone
• Number Before Noun
• Number After Noun Double Digit
• Number After Noun Digit by Digit
• Number Defining Only

Explanations:

• Number Telephone

This applies only to numbers dialed on a telephone or fax, and does not apply to extensions. All telephone or fax numbers must use this token, no matter where they appear in the sentence, and no matter what possible conflict you may see in any information following this paragraph.
[0] Transferring to 7-7-0-4-1-4-4-7-0-0 or 7-7-0…4-1-4…4-7-0-0

When combined with the optional International Telephone and Address Driver, results in:
US English: 7-7-oh…4-1-4…forty seven hundred
UK English: double seven oh… 4-1-4…4-7-double oh
Spanish: 77-0-4-14-47-0-0
And so on.

• Number Stand Alone

Applies when is NOT a telephone number, is a stand-alone, not modifying any noun, and is not a telephone number. This variable is only available when the International Telephone and Address Driver is part of the client’s package.
[1] is not in use. 1-0-4-5 (for extension, which could be 10-45 in another country)
[2] Extension is

• Number Before Noun

Applies to numbers that precede the noun that they modify, even if that noun that they modify is “understood” rather than spoken. Examples:

[1] You have messages.
[2] Mailbox contains emails.
[3] Mailbox full. Number of messages more than (understood “ # messages”)

• Number After Noun Double Digit

This applies to almost any number that is spoken in a position after a noun, and is spoken as 42 rather than 4-2. Examples:

[0] Transferring to mailbox (ie. 42)
[1] Distribution list < numberAftNounDoubleDigit> deleted. (ie. 42)

NumberAftNouns will play as double digit only up to 99, unless the International Compound Number Driver is part of the client package. Numbers over 100 are wildly complicated internationally, and almost no system plays them correctly in their international versions, varying with gender (“sex”), number and sentence placement. However, all compound numbers are outstanding with System Localizer.

• Number After Noun Digit by Digit

This applies under the same circumstances as , but is used when the playback is to be one digit at a time. Examples:

[0] Transferring to mailbox < numberAftNounDigitByDigit > (ie. 4-2)
[1] Distribution list < numberAftNounDigitByDigit > deleted. (ie. 4-2)

This may apply because the developer so chooses. Or, may be a stop gap before the International Compound Number Driver upgrade is chosen.

• Number Defining Only

System Localizer has added one type of number that is only for defining (selecting) which sentence component to initiate. The does not play a prompt, just as a phantom CV defining number does not play a prompt. The token differs from CV criteria number in that the can apply to all components of any sentence choice list, and can appear anywhere, not just as , whereas a CV criteria variable number is always limited to . Also, for System Localizer to understand that a phantom number is needed in a particular position, the token name must be included in the text of a sentence, usually at the beginning of the row/component affected by it, whereas the defining number of a CV is never included in the text. Examples:

[0] Welcome,
[1] Confirmed receipt message has been heard by < list of names >
(results in playing one name)
[2+] Confirmed receipt message has been heard by” < list of names >
(results from playing many names)
[3] To hear your messages, press 1.
[4] To exit, press star.

In the above case, 0, 3 and 4 will always play. 0 has its own variable, the name of the user. However, [1] and [2+] have defining variables that are not spoken, and only play if > 0. Which of the two plays ([1] or [2] will vary with the number of users).

PT – Pass Thrus

PassThru tokens are identified by the preceding “PT” in their names, and contain information that System Localizer does not process. Meaning, the information is in the client’s system at the time it calls up an application sentence, and that token is a placeholder in the sentence for that information, and its position is fixed in its relation to any other variable information, although the text before and after may vary by language. System Localizer will pass the “PassThru” information right back to the client for processing, but any wav files or text that should play/display before or after that PassThru will be in the correct order for the language.

Client assigns the PassThru names, thus there are unlimited possibilities. The only rules being that PassThrus must begin with “PT” and cannot contain any date, time, number, language or press (reserved for System Localizer CVs).

Example:

CS_SENT01
English: Message received from
German: Message is from
received.
Japanese:
from message received.

The Runtime Engine will provide to the system something similar to the following:

English: CS_SENT01_100_2.wav , PT_Mailbox_Owner_Name , CS_SENT01_100_4.wav
German: CS_SENT01_100_2.wav , PT_Mailbox_Owner_Name , CS_SENT01_100_4.wav
Japanese: PT_Mailbox_Owner_Name , CS_SENT01_100_4.wav

The content of the wav files “CS_SENT01_100_2.wav” are vastly different by language, as they should be. But the “PassThru” played is exactly as the client created it to be.

Thus, a PassThru is just a “place holder”. The developer should assume that the PT variable will have more text in varied places in foreign languages than with English, and thus should never hard code a PT position, but rather pass it through the Runtime Engine just like any other variable token and process it on its way out.

DATABASE STUDY

The Database Study is the overview of the content of the database, including the sentence text, the corresponding variable tokens, and any potential identifiers for multimedia or pictures that may be assigned to the Sentence.

Most importantly, the Database Study that lists all variable tokens, and their corresponding numeric order, and thus is that basis for the information that should be programmed to pass from the system to the Runtime Engine to ensure perfect output.

A few of the “general practice” rules have been broken, and the method of database organization may appear abnormal at first glance. System Localizer System Localizer is not organized in the same way as a developer of one single application might have done. Keep in mind that System Localizer is used for everything and everyone, from telecom to kiosk to software and web localization. As these technologies begin to cross, and web appears in a telecom application, the organization of System Localizer becomes an added bonus. The result of this type of DB organization includes significantly broader customization and personalization, as well as translation ease.

Many of these “rules” ( or common practices) were broken due to the need to assure proper translation. And other “rules” were broken to enhance capabilities for personalization and customization. For example, in past development, a standard sentence organization might have been:

[0] You have no messages.
[1] You have message received on
[2+]You have messages received on < onDateWDowMDo >

System Localizer offers wider variety by virtue of its implementation. The following change can be made long after the application is out in the field:

[0] You have no messages.
[1] You have one message received on
[2+]You have messages received after

Note that the “one” version became more natural, and that this application changed the date format from “without year” date with the singular version [1], to use the “with year” date with plural – all after the system had already been deployed, and without changing the application code.

Moreover, pictures, media, text or effects could also have been added that are dependent upon that change of variable.

Therefore, in studying the System Localizer System Localizer Database Study, keep in mind that all is not organized as has been in the past. There are a few redundancies, which, at first, appear abnormal, but in the long run make for a clean, versatile and highly translatable application.

DATABASE STUDY EXAMPLES

CS_CONFHELD
Your conference is scheduled to be held Please call back at that time.
VARIABLE LIST:
1.
2.

NOTE: The above is a single sentence with 2 variable tokens. This may also appear as redundant, because many systems have one single piece of information that provides both date and time. Nonetheless, the component is passed to the Runtime Engine twice in order for this sentence to function properly in all languages.

PL_CONFADD
[0]
[1] additional port has been reserved for this conference.
[2-99] additional ports have been reserved for this conference.
[100+] additional ports have been reserved for this conference.
VARIABLE LIST:
1.
2.
3.

NOTE: The above, in pre-System Localizer terms, is the same variable token 3 times. Here, is 3 separate passes to the Runtime Engine, in this case 3 identical passes. In a hard code environment, the normal approach would be to use the exact same variable 3 times. However, in System Localizer there is one assignment for each instance of usage in the Master Language. This is in order to facilitate translations into languages that require multiple versions of the above entries. Such translations will not affect the developer, but do affect the System Localizer process. Moreover, the last version #3, is processed differently at runtime. The 3rd version will be played 1-2-3 rather than 123, for which the International Compound Number Driver is required.

PL_CONFCANCEL
[0]
[1] You have selected to cancel a conference call scheduled to be held with a duration of minute and port.
[2-99] You have selected to cancel a conference call scheduled to be held with a duration of minutes and ports.
[100+] You have selected to cancel a conference call scheduled to be held with a duration of minutes and ports.
VARIABLE LIST:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

NOTE: In the above case, the list of information passed to the Runtime Engine are redundant – in this particular application. Note that 11 and 12 play “digit by digit” (1-2-3), where other numbers are “double digit” (123). It can be seen that #1 #5 and #9 are all based upon the same system information. For that matter, depending upon the system, #2 #6 and #10 may also be based upon that exact same information. #3 #7 and #11 are the same number (minutes) and #4 #8 and #12 are the same number (ports).

Later Changes:
By stepping slightly out of bounds in the original construction, as above, the developer can not only stop worrying about other languages, and assume they will function correctly, but also the developer can go back and change the format of many variables without changing the system code or the translations.

If, in the example of PL_CONF06a1, if the developer decided to change #10 variable from AMPM to 24Hr, this is easily done without touching code. If the developer decided to change all Date formats from “January 4th” to “January 4”, is easily done, again without touching code. If the International Compound Number Driver is added to the package, #11 and #12 could become double-digit numbers (123) rather than the current digit-by-digit numbers (1-2-3). And so on.

And last but not least, the formats can be changed on a language by language basis. This includes customized languages, which can be in the thousands of variations.

Summary of Database Study:
It is what happens behind the redundancy that is special… what happens in Russian when there are 5 different plurals – not just “messages” but rather “messages, messagi, messagu” and so on. The intent of System Localizer is to develop a generic, repetitive, simplified base from which all languages will function correctly, and which allows the developer to make massive changes in future externally, without touching system code.