The code administration and translation page lets you define new virtual code tables, new languages, enter all codes and their descriptions and then translate them into all languages of interest.
Perl and PHP classes retrieve the code descriptions and automatically generate HTML code selection elements in the user's language. This makes internationalization and localization of web sites and database interfaces much easier.
Traditional Code Set ImplementationsCode sets are an important part of any database. They define the choices available for codified fields and supply the human readable descriptions for display purposes.
Code sets are usually implemented as database tables, one physical database table for each set of codes.
Each database table typically needs an administration data entry page to allow for code set entry and upkeep. Also, each use of each code set requires similar but slightly different SQL and application code, an opportunity for bugs to slip into the applications.
Multilingual code sets are even more work for the programmer than unilingual code sets due to the complexity of storing and retrieving multiple code descriptions for each code, one for each language of interest.
Universal Multilingual Code TableA universal code table replaces all of the traditional individual database code tables with a single database table which is structured to hold all of the code sets in the entire database.
This saves a lot of programmer work in setting up the tables and eliminates the need to write multiple code set administration data entry pages. BabelKit provides code administration and translation utilities written in both PHP and Perl.
A single database table makes it easy to write an API for each language of interest to perform common operations such as looking up a code description or displaying code choices to the user. BabelKit currently provides APIs for PHP and Perl.
Native Language FallbackThe task of maintaining codes and keeping all of the code description translations up to date in all of the languages of interest is not always complete at any given moment.
As a fallback, BabelKit implements the concept of a 'native language'. A code value becomes defined when the native language description is first entered. If the code description for another language of interest is not yet available the native language version is displayed instead.
Code Set Display OrderIt is often necessary to specify the order in which code set choices are displayed to the user.
BabelKit has a numeric code order field associated with each code value. The sort is first by code order numerically, then by code value lexicographically. The code order field can be specified at data entry time. If the order field is not specified and the code value is numeric then that numeric value is used as the code order value. This keeps numeric code values sorted numerically by default.
Deprecated CodesSometimes codified choices go out of date and are no longer available for user selection. Simply removing an obsolete code from the code set creates a problem when it comes time to display the code descriptions for obsolete code values which are still in the database.
The solution is to mark obsolete codes as deprecated without removing them from the code set. This leaves the obsolete code descriptions in the code set for display purposes, but does not allow new data entry selection of deprecated code choices. BabelKit fully supports deprecated codes.
Phrase and Paragraph User Interface TranslationIf you have a multilingual web site or user interface which needs to display pieces of text in various languages BabelKit can help with the translation and retrieval of multilingual phrases and paragraphs.
One approach is to create a code set called 'phrase' and another called 'paragraph'. The phase set is used for one line words and phrases. The paragraph set can hold multiline paragraphs or pages of text. Check the 'Multiline Set' box when creating the paragraph set.
For software modularity it helps to use code values which are a combination of the module using the phrase or paragraph and a short name such as 'member-accepted' and 'credit-disclaimer'. That way you will know exactly which modules will be affected by a change in phrasing. Some phrases may be so universal as to be invariant, so those can be shared between modules as in 'shared-hello'.
Translation Slave SetsBabelKit can be used to make a unilingual database field look multilingual with very little work. For example, you may already have a table of city records, with a single native language city name field.
To make city names appear multilingual, create a code set called 'city' and check the 'Slave Set' box. The codes for the city code set match the city record identifiers, such as 185 or 221.
Whenever a city is added or updated call the slave method:
$babelkit->slave('city', $city_id, $city_name);Use the BabelKit Translation Utility to translate the city names into the languages of interest. When it comes time to display a city name, call up the correct city name translation like this:
print $babelkit->desc('city', $lang, $city_id);
Parameter SetsIt is often a good idea to keep any application parameters separate from the application code so that they can be changed without source code changes. Parameter sets are a excellent way to accomplish this. Parameter sets are stored in the native language only and are not translated. Use the param() method to get the data.
For example if we have a currency conversion application, we can store the currency conversion rates as a BabelKit code set. Create a code set called 'currencyrate' and check the 'Parameter Set' box. This marks the currencyrate code set as pure data and will not present it for translation in the BabelKit Translation Utility. Data entry is done in the native language only.