Hierarchy
SAP_BASIS (Software Component) SAP Basis Component⤷
BC-DOC-TTL (Application Component) Translation Tools⤷
SLXE (Package) New MLT Environment
Basic Data
| Data Element | LXEOBJTYPE |
| Short Description | Type of Translation Object |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | LXEOBJTYPE | |
| Data Type | CHAR | Character String |
| Length | 4 | |
| Decimal Places | 0 | |
| Output Length | 4 | |
| Value Table | LXE_ATTOB |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | ObjectType |
| Medium | 17 | Translation OType |
| Long | 27 | Type of Translation Object |
| Heading | 27 | Type of Translation Object |
Documentation
Definition
Object type in the translation environment.
Use
Translation object types are derived from system and transport object types, but their granularity is often finer. This is necessary because it enables you to determine the number of translation-relevant objects, which is a considerable cost factor, with as much accuracy as possible.
In the case of certain frequently-translated object types, using so-called meta object types (such as TABL for tables and REPT for report texts) instead of object types with a finer granularity makes it easier for you to specify the object type when translating directly in the editor (transaction SE63).
Dependencies
Example
Possible relationships between transport and translation objects (examples):
- LIMU MESS -> MESS (1:1)
This is often the case for LIMU objects. - R3TR DTEL -> DTEL + DE + DZ (1:n)
The rule for R3TR objects. - LIMU REPT + LIMU REPS -> RPT4 (n:1)
This tends to be an exception.
Table contents (R3TR TABU) are a special case. They are always handled as complete tables in the translation workflow, i.e. there is no special handling of individual table keys, which is not the case in the transport system. (However, if you want to translate a table directly in the short text editor, it is possible to restrict the table keys that are displayed.)
In the case of some transport object types, the object attributes determine how exactly the transport object is converted into a translation object. In the case of table contents (R3TR TABU), for example, it depends on the delivery class and the table's client-dependency. The first two letters in the name of the object type stand for table; the third stands for client-specific ("D") or cross-client ("I"); and the fourth stands for the delivery class (e.g. "W" for a system table). This results in the following translation object types:
TADA / TADC / TADE / TADG / TADL / TADS / TADW / TAIA / TAIC / TAIE / TAIG / TAIL / TAIS / TAIW
Repository objects, which can be derived from various transport object types such as dynpros, interfaces, and report texts, are handled in a similar fashion. The final digit in the object type name reflects the connection between the translation object and the original object, e.g.:
RPT1 (from R3TR FUGR)
RPT2 (from R3TR FUGS)
RPT3 (from R3TR FUGX)
RPT4 (from R3TR PROG)
CAD5 (from R3TR TRAN)
RPT6 (from R3TR CNTX)
RPT7 (from R3TR LDBA)
RPT8 (from R3TR CLAS)
History
| Last changed by/on | SAP | 20110908 |
| SAP Release Created in | 610 |
