Sw4   >   Stringtables   >   String Tables (All Contents)
One of the strengths of StudioWorks is the ability to create applications that can be switched on-the-fly to display labels, tooltips, reports, and titles in different languages.
StudioWorks originally accomplished multi-language support using the String Tables functions provided by Omnis Studio. In the 2006-01-31 release we moved to storing the labels and tooltips for different languages in a cached list in the oStringTables object. Even though StudioWorks is not longer using the Omnis Studio string tables, for backwards compatibilty we continue to use the oStringTables object and refer string tables in the code and documentation.
Whether you are developing an application for a single language or multiple languages there is virtually no extra effort on your part. In fact, the technique used by StudioWorks for implementing mutliple languages saves you a lot of typing!
StudioWorks maps string tables and rows to database tables and columns.
String tables are loaded by StudioWorks when you
.StudioWorks lets you store the language text for the application in three possible locations:
When you stringtables_*.txt files are loaded second, each adding their own language columns as needed, the database string tables are loaded last and overwrite any text file language values. The last value overwrites and previous values.
The database string tables and the text files string tables are optional. For a single language application in the meta-data text is loaded into its own set of columns, the en-us you only need to enter the language text in the meta-data.For each language the text is stored in 3 parts.
The string tables list is held in the oStringTables object class which is instantiated by the task variable stb.
The string tables master list has the following base columns:
For each language loaded by from the string tables text files or the database the string tables master list adds 3 columns. The following example is for fr (French).
The base language text for your application is stored in the schema and query classes. The StudioWorks meta-data uses en-us (English US). The primary way of entering the language text is with the which you access from the .
The
tab pane has string table fields for:The above text is used to generate the Tbl and Tblplural string tables. The values would be mapped in the string tables master list as follows:
stbname = Tbl, stbid = Book, en-us__label = Book
stbname = Tblplural, stbid = Book, en-us__label = Books
The
tab pane has string table fields for:If the above column belonged to the sCashreceipts schema class, the values would be mapped in the string tables master list as follows:
stbname = Cashreceipts
stbid = DateDeposited
metadata__label = Date Deposited
metadata__tooltip = The date the payment was deposited. Not the date received.
metadata__abbrev = Deposited
Each query class column defaults to using the meta-data from its schema class. If you point a query class to a specific string table in the Organization server table could contain names of businesses as well as households. A window for editing household records can have different labels if you create a qHouseholds query class and point it to a Household string table. (You can create an sHousehold_stb schema class which is not mapped to a servertable in the database. See Substitute String Tables.)
tab you can map all of the columns to different language text. This is useful if records in one table have different uses. e.g. AnNon-database related string tables can be created using dummy schema classes. These schema classes do not map to server tables and the schema class name is appended with _stb, or _listdef. e.g. sMn_stb
The string table name is calcuated using the cap() value of the schema class name minus the s prefix and the _stb suffix. e.g. sSomeName_stb is loaded as the string table name Somename
You can add further suffixes after the _stb suffix to define subgroups of a string table. (e.g. sMn_stb_reports, sMn_stb_buttons, ....) I do this if an _stb schema class gets too big.
Each column name in the schema class becomes an stbid in the string table list. The column description is used as the default language text. You can include a tooltip and abbreviation by delimiting them with the backquote character in the column description text.
The handy thing with storing the string tables in schema and query classes is that while you are writing code you can quickly look up any stbname and stbid in the > tab. The _stb and _listdef schemas even display the label text in a tooltip when you hover over them in the .
You can override the StudioWorks meta-data text by copying or creating _stb schema classes in your main library. The _stb schema classes found in the main library are loaded before the StudioWorks _stb schema classes.You can store string table information in a stringtables_*.txt tab delimited text file which you locate in the APP/startupitems folder. StudioWorks loads the stringtables_*.txt file during startup. Only the language columns matching the _* file name suffix will be loaded by StudioWorks. This file is required for adding languages to your StudioWorks application.
You can use the StudioWorks to export any or all of your meta-data string tables to a tab delimited text file. Once the string tables have been exported you can send the file to a translator who can fill in the additional language text.Customer changes to string tables text, whether to the base language or for additional languages, are stored in the database in a special record in the Refs table. One stringtable records is created for each language.
The
can be used for making changes to string tables or even adding new languages and saving them to the database. Changes are automatically saved to the database. Only modified values/rows are saved to the database. If the customer changes the text for 5 stbids, there will only be 5 rows in that language saves to the database.Developers should use the stringtables_*.txt files for adding languages to their application.
Customers should use the
for making their own custom changes to the language text. Those changes are saved to their own database.To delete a language from the database:
The oStringTables object class is the processor for all string tables operations in StudioWorks. The object is instantiated by the startup task variable, stb.
Right-click on stb > and select to see the various public methods available to your StudioWorks application code.
Most of the code that interacts with the string tables object is built into the StudioWorks framework.
The following sample code shows 3 different ways to get the current language text for the reports menu title.
; (pStbName,pStbID,pfLabel_opt,pfTooltip_opt,pfAbbrev_opt)
Do stb.$getTextTooltipAbbrev('Mn','Reports',Label,Tooltip,Abbrev) Returns bTranslatedOK
; (pStbName,pStbID)
Do stb.$retText('Mn','Reports') Returns Label
Calculate Label as 'Mn.Reports'
Do stb.$translateString(Label) Returns bTranslatedOK
If you make a change to your application which affects the string tables you will need to reload the string tables in order to see the new or modified string table text. To do this in StudioWorks select
If a string table or string table ID is missing, you will see untranslated text in the format .StringTableName.StringTableID. (e.g. Mn.ButtonID) When developing your application there is no immedate need to rebuild the string tables when you see untranslated text. Untranslated text has no effect on the code, it is strictly cosmetic.Each time you
, StudioWorks reloads the string tables from the various string tables locations. StudioWorks loads all the string tables into a master list and saves the master list to the your application preferences.Do app_prefs.$:StringTables_MasterList.$assign(MasterList))
This saved list is referred to as a cached list.
During startup StudioWorks checks the applications preferences for a cached string tables master list and if found, loads the cached list. This negates the need for rebuilding the string table list during startup and greatly speeds the startup time of your application.
If a customer makes changes to the string tables text they will need to reload the string tables in order to see the changes.By default each column in a query class points to the string table specified by column's source schema class.
You can point a query class to a different string table by changing the
in tab of the .For this section we will use the StudioWorks template library module sw_Contacts4_template which uses a substitute string table for the Household series of window instances.
We will limit our discussion to the following tables in the contacts module:
The Org table is being used to store both organizations (businesses, charities, non-profits, ...) and households.
To keep things simple for the user we want to use different window classes, field labels, and tooltips when the users is searching, listing, and editing household records. Rather than entering an Organization Name, we will want them to entering a Household Name, even though both fields point to OrgName column in the database.
To accomplish this we do the following:
You can embed the string table text of another string table row using <stb> tags.
The name of a window instance which displays a list of records often uses the plural name which has been specified for the base schema class used to fetch the records.
You can embed <stb> tags anywhere in the language text string. For example:
The <stb>Tbl.Author</stb> record could not be deleted from the list of <stb>Tblplural.Author</stb>.
Do not point embed <stb> tags within <stb> tags.
The default language used by StudioWorks is en-us (English US). If the language text for a different language is not found, the default language text will be returned instead.
This is helpful if you are adding en-gb (British UK). In the en-gb columns of your file you only need to add the language text where the spelling is different than the default en-us language text, reducing the amount of text you need to enter and maintain.The oStringTables property method $:AllLanguagesList returns a list of possible languages.
; Get the all languages list from the string tables object.
Do stb.$:AllLanguagesList() Returns List
The list that is returned has 2 columns (displaytext,languagecolname). The list is suitable for use in a droplist field.
The oStringTables property method $:LanguagesList returns a list of the currently available languages. The list is generated by reviewing the language columns in the string tables master list. If you add a language it will automatically be included in the list returned by this method. The current line in the list will be set to the current language.
; Get the current languages list from the string tables object.
Do stb.$:LanguagesList() Returns List
To find out the current language:
; Get the current language column name from the string tables object.
Do stb.$:LanguageID Returns CurrLanguageID
In order for a language to show up in the stringtables_*.txt tab delimited file. The column names must follow the correct syntax exactly, using the language ID, etc.
window's languages droplist it has to be included in the columns of theTo add a langauge using the StudioWorks
:Once you have created a stringtables_*.txt file any additional changes have to be done manually in . One benefit of the stringtables_*.txt file is that you can send the file to a translator, they can add the additional language text, and then send the file back to you.
If you are doing a lot of modifications to string tables files you may want to write a small Omnis Studio app which can load and merge various string tables text files. Only a few StudioWorks developers are writing multi-language apps, so if you are one of them, we're counting on your creativity to add these types of enhancements. It is possible to break the string tables text file into multiple files for separate tables and/or separate languages and get StudioWorks to load all of the string table files during startup.