This Multi Language support for T01 and T51 SyncBOs has been introduced from MI2.5 (SP18) or MI7.0(SPS09) onwards. The Architecture of S01 SyncBO has this feature implicitly enabled and hence requires no special development or steps. The following explains the steps or the development involved in enabling the existing T01/T51 SyncBOs multi language capable. The following is a pictorial representation of an existing T01/T51 SyncBO:There are 2 structures TOP and 010. K1 is the key field of the TOP structure. L4 and L5 are the language dependent fields in the TOP structure. K2 and K3 is the key fields of the item structure 010. L6 is the language dependent of the item structure 010. Steps for enabling multi language feature for the above SyncBO: 1. Identify the fields in the structures of the SyncBO that are dependent on the language. For ex. L4 and L5 are the language dependent fields in the TOP structure and L6 is the language dependent of the item structure 010. 2. The original structures that contain the language dependent fields are called the Parent or Target Structures. 3. Create additional Item Structures which are called the Language Structures or Language Source Structures by modifying the getDetail BAPI wrapper in the backend. The use of this structure is to carry the data in multiple languages for fields that are language dependent in the parent structures. 4. The addition of new structures can be reflected in the MEREP_SBUILDER using the BAPI interface check functionality for that SyncBO. 5. The language structures must contain all the key fields of the Parent structure, another key field of SPRAS domain and the language dependent fields of the parent structure. This may require creation of new structures in the backend. For Ex. Item structures 020 and 030 as shown below. For ex. In the below structures other than parent key fields K1 K2 and K3 there is an additional key field LK which will be of SPRAS as domain. L4 L5 and L6 are language dependent fields. 6. There should be one language structure created for every Parent structure. There will be 1:1 relationship between the parent and language structures ie. one language structure cannot have 2 parent structures. For Ex. In the above image 020 is for the TOP structure and 030 is for the Item structure 010. 7. The getDetail BAPI must populate the language structures with the data from all the languages. For Ex. In the above example for the language structure 020 the data returned by the getDetail is as shown below. Here data is being populated for 3 languages. 8. The above data is used by the Synchronizer to convert the data to the language of the Mobile Id during upload and download request. 9. This Language Structure must not have any relationship to any other SyncBOs or must not be associated to any other language structures. 10. The Language structures must be mapped in the MEREP_SBUILDER for language conversion to take place. If mapping is not done then the XML file will change and the MEREPS_BUILDER will treat this language structure as normal structure. 11. After mapping generate the SyncBOs and run the replicator. 12. XML file will be unaffected and hence no changes will be required to be done on the client. The language structures are not visible to the MI client application. 13. There should be no logon language maintained when creating a RFC connection from middleware to backend. 14. The Create and Modify BAPI wrappers must change the data in the backend based on the locale langauge set by the middleware. This locale language is set based on the Mobile ID’s language which is generated for the application during deployment to a user. After following the above steps, you can download data of your own language and make changes to the data in the same language for T01 and T51 SyncBOs.