For our international customers and especially those customers that operate in multiple locations around the world, RefTracker provides a number of features that ensure your system will operate seamlessly:

• RefTracker is time zone aware and always presents times in the user’s own time zone (local time), ensuring that questions submitted in one time zone can be answered in another, without any risks of the user’s deadline requirements being mis-calculated.
• If your RefTracker system supports more than one language, the names of each supported language will appear on the line above the footer. Click the language that you want to use and your RefTracker screens will redisplay in that language, until you select another language. If the selected language has multiple Locales, and more than one has been selected for support by this system, the user will be presented with the Language using their Locale and any other supported Locales for the selected language will display on this line. 
• RefTracker understands locale and tries to presents dates in the user’s preferred date format according to the Language and Locale that they select from the footer.
• RefTracker can operate in multiple languages with users being able to instantly flip their interface between languages when required. Correspondence with staff is sent in the preferred language for that staff member as selected in their My preferences (i.e. it uses the email template in that language). Staff must have the locales for all languages that they want to use, set in their languages/locales for their browser, if they want to be able to see dates and money in the local format for that language. Regular users of multiple languages will already be set up in this way.
• Correspondence with third parties is sent using the email template in the default language for the user sending the email.
• All correspondence with clients is sent in the client’s own language preference i.e. it uses the email template in the client’s preferred language, as determined from the client’s browser when they used the RefTracker client interface, or from the language tags in the header of an email imported from them. For full details on how this is determined see “What language will a user see” later in this section of this manual.
• RefTracker recognises that costs can be incurred in multiple currencies and so the currency of an incurred cost is saved along with the entered cost.

RefTracker is UNICODE compliant and supports the use of characters in any language catered for by UNICODE, ensuring that the text of questions and answers can be created by clients and staff in any language, yet be appropriately presented on screens, in print and in emails. However, the user interface (for example labels that you see on screens) are controlled by the RefTracker application, which is distributed using English. Other language options may have been provided in your system, and you can do a new translation for a new language should you need one.

Should you need the user interface to be available in any language other than English you will need to contact your Altarama representative to have the additional languages(and locales) enabled, and then either check the existing translations or provide the translations and maintain them.  A charge will apply for each language in order to cover the additional setup and support costs.

The next sections describe in detail, how to provide and maintain translations.

Languages supported by RefTracker

The Language code table (found under System>Code tables menu>System) defines the user interface language sets available in RefTracker, and allows you to define which of the supplied user interface languages will be available in your RefTracker system. Of course, if we add a new language for you, then you will need to provide the text translations that will be used by that new language interface, or check them if they have already been provided by RefTracker.

If more than one language is enabled in the Language code table, users of RefTracker will be able to easily swap between the languages by clicking the appropriate language name that then shows on the line above the footer in every RefTracker screen.

More information about the Language code table is provided in this manual under Code tables>System.

Exercise:

Ask Altarama to add or remove any languages that you do not want to use in your system. If you are currently working on a translation and do not yet want that translation to be available for general use, set the permission level for that language (in the System>Language code table) to System administrator, and set it back to client when your translation is ready for general use. Note that charges apply for enabling other languages.  When this is done you can provide the translations for that language as per the next sections.

Adding a new user interface language to RefTracker

To enable a new interface language (one for which no translations have been provided in your RefTracker system) you need to do the following:

1. Have the language added to the Language code table (as described in the Exercise above)
2. Translate all the literals
3. Translate all code tables that are in use (including General codes, Application functions, and Page titles)
4. Translate all field labels in the Data Dictionary
5. Translate all field labels, notes and text in Request forms
6. Translate the templates that you are going to use (text, email and print)
7.  Provide translations for the text in the “1 – names & contact information” Parameters
8.  Provide your support representative with translations for the terminology you use for your “request/question” and “requester/client/end user”, so they can update the database table names for these terms (as these names are used within text throughout the system).

By doing the above steps both the staff interface and the client interface will be translated. Additional notes have been provided below for those who just want to translate the client interface.

When doing the bulk translation exercise we recommend the following method:

• Open RefTracker in English (initially) in one browser (e.g. Internet Explorer), go to System>Utilities>Administration utilities> Literal editor, then change to the language that you want to do the translations for. You will see the English versions of the literals with “(en)’ after them to indicate that they have not yet been translated.
• In a different browser (e.g. FireFox), open RefTracker, also in English for the time being.
  In the second browser, go to the page that you want to translate.
  Review the page you want to translate in a language with a complete translation (such as English), then review it in the new language that you want to create by changing languages at the bottom of the screen. Then in your other browser (the one running the Literals editor) change to Page specific at the top of the page, then choose the specific page you want to translate and click Search. Translate all the literals shown for that page. If you are unsure of the context of any literal, go the other browser where you have that page showing, and swap between the language you are translating from, to the language you are translating to, see the literal in context. As you provide new literal translations you will be able to see them start appearing for that language in your second browser.
• If a value has been entered for a language, but is not yet in the language in which you are viewing it, you will see the value provided in the other language with the bracketed code for the language it was created in, after it e.g. “Response (en)”. For each of those untranslated literals you will need to provide a translation using one of the steps 1–6 above. More details about how to undertake steps 1-6 are providing in the following sections. This example uses the Literal editor, but in the other steps you need to use other functions such as code tables to provide the translations. The process is the same no matter what tool you are using – go to the page for which translations need to be provided – ensure that you are viewing the page in the language for which you want to provide the translation, and then replace the text ending with “(en)” with the equivalent text for the language you are translating to. Note that the bracketed language code is only added if there is enough space in the field to add the extra characters, so some very long values (like code tables with more than 45 characters) will not have that language code suffix.

Making minor changes after a language has been set up is exceptionally easy – just go to the place in RefTracker where the change needs to be made – make it in one language, then select each of the other languages that you support using their name in the line above the footer, and change the newly added or changed entry for that language, until all languages have been done.

What language will a user see?

If you have more than one language or locale enabled in your Language and Locale code tables, and the language is not specified in the URL used to access RefTracker, the language users will see in the client interface pages when they first use it will be:

• For staff, the language that they last used in this session (as saved in the RefTrackerPreferences cookie), but if logging in, the system will revert to the Default language specified in their signon/My preferences>Contact details tab>Locale parameter.
• For clients, the language specified in the RefTrackerPreferences cookie if one has previously been saved for that client, or otherwise the language determined from their browser if that language and locale is supported by this RefTracker system, or otherwise the default language (and locale) as specified in this system’s Language code table.
  Locale is saved in the client table for each question so that follow-up correspondence with the client can be provided in the right language and using the right date formatting. 
  Locale is determined from the LCID of the client’s web browser or from the language tags in the header of the email, if the question arrives by email.  If a locale cannot be determined from either of these the locale will be set to the locale of your RefTracker system as defined by the language in use in the System>Language code table.

More information is provided in this manual under Code tables>System – see the Language and Locales code table information.

Changing/Translating the literals

Literals are the text used for things like Labels and Descriptions in RefTracker screens. Some text is controlled by system code tables or text files, and they will be addressed in the next sections. If you cannot find the text you want to change in this literals editor, you will need to look for it in the Data dictionary, Code tables or the 4) Text parameters (generally these provide large block of text).

You can change the literals used in RefTracker using System>Utilities>Administration utilities>Literal editor. RefTracker provides Default text for each language (once the language has been initially set up), and the ability for you to specify your own user defined text for each literal by providing alternative text in the “Local text” field (when viewing the page with the language for which the change needs to be made, selected). If a literal is changed by a software upgrade, only the default text will be changed. In this way, any local customisations that you have made by providing “Local text” are protected from software upgrades. This means that you can customise any language to match your local terminology.

Details of how to use the Literals editor page are provided in the Utilities>Administration utilities section of this manual).

Important information that you need to know when providing translations is that if you use more than one language, your change will be copied into that same literal for all languages that you have enabled, however in the other languages it will be suffixed by the code for your current language, in round brackets, e.g. “(En)” for English, in order to indicate that is a default setting. You will need to remember to make the same change for all languages that you use – the bracketed language code suffixes should act as a reminder to you that the entry still needs to be translated.

To make an equivalent change for a different language, note the code for the literal that you just changed. Immediately after you have made the change, click the language name in the line above the footer for which you are providing the translation. You will then be presented with a page of literals from the language that you just chose that includes the same literal – you will have to pick it out by its code. Make the equivalent change to the literal in that language that has the same code.

Where a literal contains text in {curlyBrackets}, do not translate the curly brackets or the text that they surround, as this is a RefTracker variable that is substituted by an appropriate value at run time.

The easiest way to change literals in different languages is to search for them by page number – that way when you change language you will see the same set of text. If you search for specific text then when you change language, it will (logically) search for that text (e.g. “Search” in English) in the new language and bring back a different set of Codes (i.e. it will not find “Rechercher” which is the same thing in French).

A good way to do the literals translation is to have RefTracker running in two browsers. In the first bring up the literal editor and view it in the language for which you are doing the translation. In the second (it must be in a different browser) bring up the page that you want to change the literals for. Review the page you want to translate in a language with a complete translation (such as English), then review it in the new language that you want to create, by changing languages at the bottom of the screen. Then in the browser running the Literals editor change to Page specific at the top of the page, then choose the specific page you want to translate and click Search. Translate all the literals shown for that page. If you are unsure of the context of any literal, go the other browser where you have that page showing, and swap between the language you are translating from, to the language you are translating to, see the literal in context. As you provide new literal translations you will be able to see them start appearing for that language in your second browser.

Note that:

• Literals noted as “not page specific” can occur anywhere in RefTracker and so should be translated.
• Pages with page numbers of less than 400 are used in the client interface – you will want to translate all of them.
• Pages with numbers between 400 and 899 are used by your staff operators and you may well want to also translate them.
• Pages with numbers of 900 or over are ONLY used in the Administration functions (those under System) – you only need to translate them if your System administrator wants them translated.
• Don’t forget that not all literals are page specific. Even following these instructions you will still need to review each translated page, and if not all text has been translated, Search for it in the Literal editor screen using some text from within the literal, and then amend it.

Changing/translating entries in code tables

To provide a translation for an entry in a code table, simply display the code table in your main language and make any changes that you need to make (if your main language is English you may not need to make any changes at all).

Then choose another language from the line above the footer of that screen, for example Français, and the French values for that code table will display. Make the equivalent changes in this language.Any newly added entries will display with a postscript code for the language in which they were originally entered e.g. “(En)” for English, indicating it is a value initially entered via the English version of this code table. They are a cue that the entry still needs to be translated.Do this same step for all other languages that you support.

Where a code table entry contains text in {curlyBrackets}, do not translate the curly brackets or the text that they surround, as this is a RefTracker variable that is substituted by an appropriate value at run time.

If you are doing initial translation for your system you will need to provide translations for all code tables that you use.

Go to System>Code tables menu>General codes and provide translations for all of these code tables.

Then go to System>Code tables menu>General codes and provide translations for all of these code tables except Locale and URI scheme. Languages will already have been done as a result of instructions above). The Application function code tables, and the Page title code tables are important to translate as they determine the main screen names and navigation links.

Many of the remaining code tables may be changed or disabled during the System Administration training and setup assistance, so leave translating the following until after you have the system working the way that you want. When you are ready to do these last Code tables:

1. Go to System>Code table menu>Question input. Disable any code tables that are not ticked as being used in Request forms or by the System (you do not need to translate code tables that are not in use).
2. Similarly there may be some code tables that you can disable under System>Code table menu>Answering questions, but you will need to review each enabled code table individually to determine whether you need to translate them.
3. Then go to System>Code table menu>Other and for each of the user defined entries, translate any enabled code tables.

Changing/translating entries in the Data Dictionary

To provide a translation for an entry in the data dictionary, simply display the Data dictionary table in your main language and make any changes that you need to make (if English is your main language, you may not need to make any changes).

Then choose another language from the line above the footer of that screen, for example Français, and the French values for that Data dictionary table will display. Make the equivalent changes in this language.Any newly added entries will display with a postscript code for the language in which they were originally entered e.g. “(En)” for English, indicating it is a value initially entered via the English version of this Data dictionary table. They are a cue that the entry still needs to be translated.Do this same step for all other languages that you support.

Provide translations for all of the tables under Data dictionary – the Question tables and the System tables. This is best done after your System administration training and setup assistance as changes to Data dictionary entries will generally be made during that time.

Changing/translating text in the Request forms

Translations will also need to be provided for all of the text in all of the Request forms that you want to make available in other languages.When the design of your request form is perfect in your main language (after the System administration training and setup assistance, and possibly even after your testing period after that), choose another language from the line above the footer of that screen, for example Français, and the French version of that Request form will display with all of the text that it uses. Translate all of the Labels, Field notes, Division notes, and Display fields using Edit layout, and then using Edit defaults, translate any prepopulated text defined in that screen.Notice that in the French version of this request form, all the code table values are already showing as the French version of the selected code table.Do this same step for all other Request forms that you have enabled, in all other languages that you support.

Changing/translating the templates (text, email and print)

Your RefTracker system uses a number of text files.  You can minimise the use of some of these by configuring them out using the 4.x parameters.
For the ones that you will use, you can modify them using System>Utilities>Administration utilities>Template editor (text)

Similarly, translations will also need to be provided for all of the email templates in your system, and any of the print templates that you use in other languages.

To edit your email (and print) templates go to System>Utilities>Administration utilities>Template editor (email or print).

The templates are arranged in directories for each language. The templates that show in the System>Utilities>Template editor screen are the ones for the language you are currently using.

To edit the templates for another language, choose the language from the line above the footer. The screen will redisplay showing the templates in the master and local directories for the newly selected language.

RefTracker automatically copies any new email template that you create, into all other languages that your system supports one. It will be in the language that you first created it.  You MUST remember to translate all new email templates for ALL languages that you support.  We recommend taking copies of all our translated email templates before you start translating and then another backup afterwards, as it is easy to accidentally overwrite work when doing this task!
However if you make a change to an already existing email template, RefTracker cannot automatically copy over that change – you must remember to make that change in each of your supported languages.

When a new language is first set up the Master templates will still be in English. You will need to copy each template to the local directory and translate it. Your local translated versions will be used in preference to the master ones in English as long as your local versions have the same name.  If you advise Altarama when the translations are complete, we can load them as the master templates for that language.

If the master templates have all been translated, it is time to ensure that there are translated versions of any user defined templates. For each user defined template that needs to be used in another language – when you have its layout perfect in your main language – use the Download function in the Systems>Utilities>Template editor screen to copy the template to your local computer.Then in the Template editor screen, change to another language, for example Français, and use the Upload function in that screen to upload the template you just saved to your local computer. It is important that you retain the same name for the template. Now you can translate the template into the new language, for example French, by using the edit function in that screen.Do this same Download, Upload, and Edit process for all other languages that you support.

When doing these translations, it is important to keep the files names used for the templates the same, to keep all $rvb$ and $rve$ coding, and to ensure that any text in {curlyBrackets} is not translates as this is a RefTracker variable that is substituted by an appropriate value at run time.

You only need translate email templates that are in use in your system, and for which the content need to be available in other languages.

If you are primarily concerned with translating emails that go to clients then the templates that you need to translate are:

• refm110.htm
• refm230.htm
• refm240.htm
• refm260.htm
• refm440.htm
• refm455.htm
• refm500.htm
• refm501.htm
• refm504.htm
• refm506.htm

Changing/translating text in JavaScript

Not all JavaScript text (text in pop ups) is available as literals.  Mostly this is error messages that need to be provided to Altarama in English, but if you have a particular need to translate something provided by JavaScript (or in fact anything that you cannot find), please contact your Altarama support representative.

Maintaining a language after provision of the initial translations

At each new release of RefTracker new functionality is delivered, and as you work with your system you will add new Request forms and templates. If you support more than one language, you will need to keep this in mind on an ongoing basis and ensure that the following things are done:

1. Additional translations are provided for the new and changed literal entries provided in each new RefTracker release.
2. As you add or change Request forms and/or templates, be sure to swap to your other language/s and make the equivalent changes. If you support more than one language each of your request forms will be available in all of those languages, so it is important that you properly maintain ALL languages for ALL of your Request forms and all custom Templates used with that form.

Making changes after a language has been set up is exceptionally easy – just go to the place in RefTracker where the change needs to be made – make it in one language, then select each of the other languages that you support using their names in line above the footer, and change the newly added or changed entry for that language, until all languages have been done.

Money in international systems

RefTracker can handle costs in multiple currencies.

Decimal parts of an amount of money are indicated by “.”  Using the number pad on your keyboard will make entering costs easy – only numerals and the point (.) character can be entered in the “Cost incurred” field.  The symbol used here is dependent on on your browser detected  Locale.

If you only need to handle money in one currency, go to System>Code tables>Other>International money codes and ensure that your currency is set as the default and is the only currency enabled. Systems set this way, will not ask for a currency to be selected when recording costs, and will not use a currency symbol.

If you operate in more than one Country or have costs arriving in other currencies, you will need to use multiple currencies in your RefTracker system:

1. Go to System>Code tables>Other>International money codes and set your most commonly used currency as the default and enable all other currencies that you want to use in your system.
2. For each user, set the “Default currency” setting in their Signon Contact details tab, to the appropriate currency for that user – or have each user set it for themselves.

When more than one currency is enabled like this:

• the Record costs screen will provide a drop down box that allows the currency of an amount being entered, to be selected, the default being the default currency set in the signed on user’s My preferences.
• the costs showing in the Summary, Journal tab will show the International currency code applicable to that cost, if the cost was recorded in anything other than the signed on user’s default currency.
• the total costs at the top of the Summary screen Journal tab, and in the Details tab, will show without a currency code if the total costs incurred are all in the signed on user’s default currency; will show with the applicable currency if the total costs are in a currency other than the signed on user’s default currency; or will appear as “–.–” if costs have been incurred for this question in multiple currencies. 
• the Billing rate code table will also allow the currency to be specified so that staff billing rates will be able to be specified in the user’s local currency.