W.I.P.

Guide to OFBiz-i18n, Internationalisation of OFBiz

Looking around the WIKI there are few hints (and even less concrete guides) towards what needs to be done in order to add more locales to an OFBiz setup, namely the current release or SVN trunk.

Most generally, there are three areas of concern when starting a translation of OFBiz into a different locale, i.e. a language and possibly a specific sub-locale:

Translation of Application labels
Translation of OFBiz assets with built-in i18n options (Catalog, Product)
Translation of Text Elements (DataResources) using CMS

However, i18n goes even beyond that as there is a clear (natural) preference for US standards-based demo data, e.g. in the area of PaymentGateways, ShippingInterfaces and Accounting in general (tax allocation, general ledger configuration). Hence a fourth section tries to address these areas:

Re-configuration of General Ledger
Tax configuration
Extension of GeoData

Note that this document focusses on the CONFIGURATION of OFBiz Entities in order to display Text in a different Locale and possibly pay attention to different Legislation & Taxing in other Locales. This document does NOT aim to talk about technical localisation (Tech Folks, make sure you start at Adrian's Internationalization) or adding more local payment or shipping gateways, as t his is considered regular customisation.

A final section covers tools that can be used for the translations tasks and documents present in this wiki which refer to translations.

Translation of Application labels

The labels for the OFBiz GUI applications are the most evident part to change for an i18n project. They are part of the release and serve the purpose of 'resource packs' known from claqssic Java development.

Also refer to Tips for UI labels translation.

Location of config files

located in the configuration subdirectories as follows:OFBIZ_HOME/applications/<appname>/config

OFBIZ_HOME/framework/<appname>/config

OFBIZ_HOME/specialpurpose/<appname>/config

The naming convention is <appname>UiLabels.xml.

Most likely there will also be <appname>HelpUiLabels.xml, <appname>EntityLabels.xml and possibly other files there. Just check through an see what merits your translation.

Activation

The activation of changed configuration files is easy: Restart the OFBiz application. These configuration files are read in every time the OFBiz application container starts. Hence: Edit > Save > Restart > Use is the activation sequence.

References to other Wiki Documents

Interested to understand how you make references to the i18n labels in code? Then read this: Text Translation.

Translation of OFBiz assets with built-in i18n options

This section assumes you have understood the relationship of Content, ContentAssociations and DataResources. Also, you should understand how a DataResource can be provided to the system.

Some OFBiz entities have built-in i18n options, the most prominent (and evident) are Catalog-Categories and Product. Check out how to translate Products or Categories Name and Descriptions, have a look at How to localize Product and Categories descriptions.
You can find out which entities provide this option when searching for "*Content" in the entitymodel.xml configuration files (which will then list out all occurencies of a <entityname>Content entity). Search in the current trunk (rev 811440) resulted in the following Content-Entities:

applications / order --> OrderContent
applications / party --> PartyContent
applications / party --> CommunicationsEventContent
applications / product --> ProductCategoryContent
applications / product --> ProductConfigurationItemContent
applications / product --> ProductContent
applications / workeffort --> WorkEffortContent

Most typically, the entity.name, entity.description and entity.longdescription attributes can be internationalized. A table listing the i18n options of respective entity attributes will be worked in here soon.

NOTE

When using i18n on these entities, the "direct" attributes must be empty, otherwise the CMS lookup will not occur.

TIP

Each of your Content and DataSource items will need a unique ID, so make up your mind about naming conventions for the ContentId and DatasourceId that are related to your entities!

ProductContent special remarks

The ProductContent entity will be the most interesting one for ecommerces since working on the product descriptions will be the most of an online editor's work. Also customizing text for different locales when you run a multi-locale shop will be a huge task. Best results are achieved when an XML template is used that defines all relevant entities for a new product (make sure you use a single XML per single product).
Aside the regular relationships of a given product (configuration elements, category placement etc.), the i18n content elements should be added with the same XML. Then at least a template CMS structure will be present with each product that is uploaded.
Unfortunately the Demo data just places rudimentary i18n. The relevant attributes to i18n on a Product are:

Product.name
Product.description
Product.longDescription
The corresponding relationships are built using the ProductContent entity where the productContentTypeId should be set to 'NAME', 'DESCRIPTION' or 'LONG_DESCRIPTION' for the content that will map to name, description or longDescription respectively (attention, the Demo Data does not define the LONG_DESCRIPTION content items, so you will need to touch this, sorry!).

TIP

By default, the productContent.description entries are also used in <HTML><HEAD>...<META type="keyword" ...> tags, so using this can help you with localized Search Engine Optimisation projects.

MORE TO COME SOON (worked example)

Translation of Text Elements using the CMS