Open Source Strategies
 
Main
About
Learn More
Services
Projects
Jobs
Contact

SourceForge.net Logo

Standardizing and Internationalizing OFBiz User Interfaces

It is a good practice to follow these instructions, even if you do not initially plan to internationalize your application. They would help you keep your user interface labels in a standard .properties file, so you make global changes, customization, and translation easier for you and your users later on.

Translating an Existing Application

It is fairly easy to translate OFBiz to other languages, and OFBiz has already been translated, at least partially, to French, Italian, German, Spanish, Portuguese, and Chinese. Translating OFBiz into another language just involves creating a new translation file.

Inside each OFBiz applications/ directory is a config/ directory where configuration properties and language translation files are. For example, in the order manager application, you will find the following files in the config/ directory:

sichen@linux:~/eclipse/workspace/ofbiz> ls -1 applications/order/config/
OrderErrorUiLabels_fr.properties
OrderErrorUiLabels.properties
OrderUiLabels_de.properties
OrderUiLabels_fr.properties
OrderUiLabels.properties
OrderUiLabels_pt_PT.properties
OrderUiLabels_zh.properties
taxware.properties
zipsales.properties

The files OrderUiLabels_xx.properties and OrderErrorUiLabels_xx.properties are the translations of user interface (UI) labels to other languages. "xx" is the standard locale code of a specific translation and comes from the getAvailableLocales() method of the Java Locale class, via an OFBiz API called UtilMisc.availableLocales(). For example, "zh" means Chinese, "fr" means French, "de" means German, "pt" means Portuguese.

Each UI labels translation file is a properties file of UI labels (usually in English) and their translation into the language of the locale. So for example, here is what the French labels for the OFBiz order manager looks like:

FacilityBillingAddressSameShipping = L'adresse de facturation est la m\u00eame que celle de livraison
FacilityDeliveryOrder= Bon de livraison
FacilityFacility = Service
FacilityInventory = Inventaire
FacilityNoFacility = Aucun Service
FacilityNoOtherShippingMethods = Par d\u00e9faut : Aucun autre moyen de livraison possible
FacilityShipAvailable = Livrer les produits d\u00e8s qu'ils sont disponibles (peut occasionner des frais additionnels d'exp\u00e9dition)
FacilityShipOnceOrAvailable = Livraison compl\u00e8te ou partielle ?
FacilityShipmentDatas=Donn\u00e9es r\u00e9ception
FacilityShipments = Livraisons
FacilityShipping = Livraison

To translate OFBiz to a new language, create a new properties file for your locale.

Using UI Labels for Internationalization

If you are developing new screens, you will want to reference the UI label files so that you can re-use them. In the OFBiz screen-widget, you can reference UI labels using the <property-map> tag inside a screen's <actions> section. For example, the following code from the order manager's "main-decorator" screen loads UI labels from different applications:

    <screen name="main-decorator">
        <section>
            <actions>
                <!-- base/top/specific map first, then more common map added for shared labels -->
                <property-map resource="OrderUiLabels" map-name="uiLabelMap" global="true"/>
                <property-map resource="AccountingUiLabels" map-name="uiLabelMap" global="true"/>
                <property-map resource="EcommerceUiLabels" map-name="uiLabelMap" global="true"/>
                <property-map resource="ProductUiLabels" map-name="uiLabelMap" global="true"/>
                <property-map resource="ManufacturingUiLabels" map-name="uiLabelMap" global="true"/>
                <property-map resource="WorkEffortUiLabels" map-name="uiLabelMap" global="true"/>
                <property-map resource="PartyUiLabels" map-name="uiLabelMap" global="true"/>
                <property-map resource="CommonUiLabels" map-name="uiLabelMap" global="true"/>

Note that the typical pattern is to reference the needed UI labels in a main layout or decorator screen and then reuse that screen throughout an application, so you would not need to reference it over and over again for each screen.

Then, when you are actually writing your screens with freemarker templates (.FTL) or form-widget XML files, use ${uiLabelMap.

Internationalizing data types

Subsequent to opentaps version 0.9, it is also possible to internationalize the data types stored in the database, so "Purchase Orders" could become "Acquisto" in Italian. The following steps are required:

  • Create a series of translation files for each locale for your data labels, such as OrderEntityLabels_it.properties for Italian and OrderEntityLabels.properties for the default US English. Put these files in your config/ directory as above.
  • In the entitymodel.xml, add the following to your <entity> definition:
    default-resource-name="OrderEntityLabels"
    
    to point to your data labels file.
  • When you display the order fields, use the .get(field, locale) method for the GenericEntity or GenericValue, instead of .get(field), like this:
    ${orderType.get("description", locale)}
    
    This can be done either in a form-widget or on an FTL freemarker template.

For an example of this, see SVN r 7557.

Internationalizing a New Application

To internationalize a new application, you would need to make sure that the config/ directory is loaded for the application. This can be done by adding the following line to your ofbiz-component.xml:

    <classpath type="dir" location="config"/>

Contributing your Translations Back

By contributing your translations back to the open source project, you can help create a community of other users in your country. Those users may, in turn, help implement features which would help you, especially country- or region-specific features. You can also establish yourself as an expert for your country or region, should other users require help.

To contribute your translations, create a JIRA issue for the OFBIZ applications or a SourceForge.net issue for opentaps and upload a patch file of your .properties translations. A patch file is created with

$ svn add file1 file2 file3
$ svn diff file1 file2 file3 > mychanges.patch
where file1, file2, file3 are the files you've changed. If you've created new files, the add step is necessary. Otherwise, it can be skipped. For consistency, please make all your patch files from the opentaps/ or ofbiz/ root directory.


© 2005-2007 Open Source Strategies, Inc. All rights reserved.