Page History

Introduction

OFBiz is used all over the world by companies doing business in their own country or internationally. This has been recognised early on in the project as being key to the adoption of the project and its works, and to have an internationally diverse community.

Though the default language for code, titles and other messages, and data is English, translations of these elements are essential and many participants in the project have contributed translations to these elements.

The OFBiz rendering engine ensures internationalisation for:

• entity data translation
• service messages translation
• widget element translation
• content translation

Generic construct of a translation definition

A translation definition is defined in an xml file and governed by the ofbiz-properties.xsd (see https://ofbiz.apache.org/dtds/ofbiz-properties.xsd" ). Translation definitions are also called OFBiz labels, as they are processed through the UiLabelMap services and functionality.

A translation definition looks like:

<property key="<ElementIdentifier>">
     <value xml:lang="<IETF-LanguageTag>"><TranslatedValue></value>
</property>

whereby:

1. the <ElementIdentifier> is the identifier of what is to be translated, This element is registered in CamelCase, e.g. ProductOverview
2. the <IETF-LanguageTag> is the language that the renderer is to use for the proper translation, and is in accordance with the IETF BCP 47 language tag definitions, e.g. en, or en-us
3. the  <TranslatedValue> shows the value of the <ElementIdentifier> in the defined language (<IETF-LanguageTag>)

An example of this:

<property key="BicycleRack">
     <value xml:lang="en">Bicycle Rack</value>
     <value xml:lang="en-us">Bike Rack</value>
     <value xml:lang="nl">Fietsrek</value>
</property>

Entity data translation

The translation definition for entity data follows the general construct for a translation definition as described in the section above.

Translation definitions for entity data are located in the <Component>EntityLabels.xml file within the 'config' folder of the component related to the entity definitions in the files in the  entitydef folder  in the datamodel component. 

As an example:

The entity Product is defined in the product-entitymodel.xml file. As such the data translations for the Product entity go into the ProductEntityLabels.xml file in the config folder of the product component.

Translation of entity data through the rendering engine is facilitated through property files contained in the config folder of the appropriate component(s), associated with the entity model and data files in the data model component. 

A translation defintion for entity data translation looks like:

<property key="FieldDescription.<EntityName>.<fieldName>">
     <value xml:lang="<IETF-LanguageTag>"><TranslatedValue></value>
</property>

whereby the property key value has the following elements:

1. the fixed value FieldDescription, followed by
2. a dot (.), followed by
3. the name of the entity in camel case as represented above through <EntityName>, followed by
4. a dot (.), followed by
5. the name of the field defined within the entity in the entity definitions file as represented above through <fieldName>.

As an example:

the entity ProductStore has a field named storeName. The translation definition for this field would thus be defined as

<property key="FieldDescription.ProductStore.storeNaem">
     <value xml:lang="en">The Bicycle Store</value>
     <value xml:lang="en-us">The Bike Store</value>
</property>

An additional translation definition has been defined for the id field of another entity, that is used through a foreign key relationship.

The definition for this translation definition looks like

<property key="<EnityName>.description.<idFieldNameValue>">
     <value xml:lang="<IETF-LanguageTag>"><TranslatedValue></value>
</property>

whereby the property key value has the following elements:

1. the name of the entity in camel case as represented above through <EntityName>, followed by
2. a dot (.), followed by
3. the fixed value description, followed by
4. a dot (.), followed by
5. the name of the id field defined within the entity in the entity definitions file as represented above through <idfieldNameValue>.

As an example:

the entity Product has a field named productTypeId, for which a relation is defined to the entity ProductType. The entity ProductType  has a field named description. The translation definition for the productTypeId field in product data records would thus be defined as

<property key="ProductType.description.ASSET_USAGE">
     <value xml:lang="en">Fixed Asset usage</value>
     <value xml:lang="en-us">Equipment Use</value>
</property>

Service message translation

Service messages, such as error or success messages and others,  are generated by functions (in Groovy, Java, Javascript and xml files). These messages are typically shown in log files and through the render engine on screens to the user.

A translation definitions for service messages follows the general construct for a translation definition as described in the section above.

Translation definitions for service messages are located in the <Component>ServiceLabels.xml file within the 'config' folder of the component where the groovy, java, javascript or xml function is initially defined.

As an example:

When the a function in categories services returns 0 products that meet the defined select criteria the function could call the translation for message 'categoryservices.product_not_found'. The translation definition would then be:

<property key="categoryservices.ProductNotFound">
     <value xml:lang="en">Product not found</value>
     <value xml:lang="en-us">Product data is not available</value>
     <value xml:lang="nl">Product niet gevonden</value>
</property>

As the function for this categoryservices function is to be included in the product component (due to the aspect that category as entity is defined in the product-entitymodel.xml file), the translation definition for categoryservices.ProductNotFound is to be included in ProductServiceLabels.xml in the config folder of the product component.

Widget Element Translation

A translation definition can be applied to particular widget definitions, like screen titles, form, grid, field labels, screenlet titles, container and  label text, etc. These translation definitions can be applied within both widget definitions in xml files and in Freemarker template (.ftl) files for forms, grids and fields

The translation definition for a widget element follows the general construct for a translation definition as described in the section above.

Translation definitions for a widget element translations are located in the <Component>UiLabel.xml file within the 'config' folder of the component where the translation is initially to be applied (can be business domain specific, eg com related translations in the marketing component).

Widget Element Translations are handled by the render engine through the incorporation of following construct:

element="${uiLabelMap.<propertyKeyValue>}"

whereby the construct has the following elements:

1. element is the attribute (according to ofbiz xsd file) that is defined to work with translations
2. uiLabelMap is the fixed element used by the render engine to apply its translation function, followed by
3. a dot (.), followed by
4. the name of translation definition as represented above through <propertyKeyValue>.

An example:

Pretend there is a need to show in a screen widget in the accounting application a label widget having text "Welcome to the main page of this application". This label widget would then be:

<label text="${uiLabelMap.WelcomeMessage}"/>

The translation for this label test would then be:

<property key="WelcomeMessage">
     <value xml:lang="en">Welcome to the main page of this application</value>
     <value xml:lang="en-us">Welcome here</value>
</property>

Field label translation

Field label translations are a special case of widget translation as they are related to field definitions included in the 

Content Translation

Internationalization

OFBiz is used all over the world by people of different languages and cultures - due to its strong support of internationalization. That support is acheived by:

...