Creating Resource Bundles  |  FAQ

 

Multi-language Support for Smart Sync-based Applications (I18N)

Global players and companies from countries with multi official languages (e.g. Switzerland, Belgium, Canada) want to serve their mobile employees with their regional language. MI's approach for I18N supports displaying client-side texts in different languages, but how about language-dependent texts that belong to objects in the backend?

One example here is master data (like equipments, countries, currencies etc.) that are replicated from the backend onto the client and that carry language-dependent text fields (the equipment's short text, long text, the currency's name, the country's name etc.). The unfortunate truth here is that Smart Sync only replicates an object instance (like one piece of equipment, one country etc.) in the logon language of the RFC user who initiated the replication.

In case of Timed-2-way SyncBOs, this implies that the logon language of the batch user who was used for replication determines the language of the object's text - the client-side logon language is disregarded here. In case of 2-way SyncBos, the language depends on how the RFC desination is set up: a) if it is set up as a Trusted System relationship, then the device user's WebAS logon language (defined by the client-side property MobileEngine.Sync.Language in file MobileEngine.config ) determines the language for replicated texts; b) if the RFC destination uses a fixed RFC user, password and language, then it is this language that determines the language of texts.

Now how to overcome the above-described shortcoming? Are there workarounds to that?

As always, there is a workaround to everything, but since the above issue is deep in the architecture of Smart Sync, neither of them can really be recommended highly. You'll need to eventually decide for yourselves which way you choose.

Solution A - One WebAS per Language

The officially supported solution is to have one dedicated Web Application Server for each language. In this case, you would group the users into groups that share the same language and all users of this group would synchronize against the same WebAS. The WebAS in turn would have the RFC destinations for all SyncBos specified in such a way that the language for all objects' texts is identical to the user group's language. Your landscape topology would then look like this:

The advantages of this solution are:

The disadvanges are the increased TCO and administration effort for having multiple WebAS.

Solution B - One SyncBO per Language

Your only alternative is that you again group users by language but now use language-dependent copies of the client applications. The applcations are completely identical code-wise, but are using language dependent copies of the same SyncBos. The SyncBos are language dependent in the sense that they are identical in all their fields and relatonships to other SyncBos, but the RFC destination that they are using is using a specific language. The SyncBos would then be identical semantically, but technically different. During replication, the same backend object would therefore be copied to the Replica DB twice (once per SyncBo) and be held there as independent copies.

The architecture of your entire mobile solution would then look like this:

The advantages of this solution are that

Disadvantages are