Translating Objects Directly 
You can call up and translate individual objects directly in transaction SE63, without calling up a worklist.
Our general recommendation is that you translate objects via a worklist. However, you may need to access an object directly in the following situations:
The system in which the translation is required is not set up for translation.
You only need to edit a single object. If this is the case, it is quicker to access the object directly than to call up a worklist for several objects.
Integration
There are different ways of accessing objects directly for translation in transaction SE63:
Using the SE63 menu
Using the text type ID
Using the object type ID
Using a meta object ID. These IDs are not available for all object types.
Using the transport object. See: Translating Transport Objects
For an exact description of how to call up objects directly, see Calling Up Objects Directly for Translation in SE63.
Prerequisites
If you want to call up objects directly for translation in transaction SE63, you need the following information:
Object type
Technical name
Features
When you call up objects directly in transaction SE63, an entry screen appears that requires you to specify the technical name of the object, the translation area to which the object belongs, and the source and target languages. Each object type has its own entry screen.
The system opens the object in the appropriate editor, such as the long text editor when you call up an ABAP long text.
Text Type IDs
The following text type IDs are available:
s for ABAP short texts
d for ABAP long texts (standard documentation)
o for other ABAP long texts
t for transport objects
x for non-ABAP interface texts (fragments)
y for non-ABAP interface texts (sentences)
z for non-ABAP texts with their own formatting
For more information on text types, see Transaction SE63 and read the "Features" section.
Meta Object Types and R3TR Transport Objects
If object types have multiple R3TR transport objects in the transport environment, they are divided into subtypes in the translation environment to standardize the references from translation to the R3TR transport objects. This affects user interface texts, report texts, Screen Painter texts and headers, field selections, developer interface documentation, function titles, and function groups. In the translation environment, the R3TR transport objects are identified by the numbers in the object type IDs as follows:
1: FUGR (function group)
2: FUGS (function group with customer include: SAP part)
3: FUGX (function group with customer include: customer part)
4: PROG (program)
5: TRAN (transaction)
6: CNTY (context)
7: LDBA (logical database)
8: CLAS (class)
Example
RPT1 = text elements for function groups
SRT4 = Screen Painter texts for programs
The R3TR transport object for a translation object influences the technical name used to access the object directly. The following conventions apply:
FUGR: Remove SAPL from the object name
FUGS: Remove SAPL from the object name
FUGX: Remove SAPL from the object name
PROG: Leave SAP* in the object name
CNTX: Remove CONTEXT_S from the object name
LDBA: Remove SAPDB from the object name
CLAS: Remove the equals signs (===) from the object name
Example
The system contains the report SAPLORG. To translate the function group texts (RPT1) directly, access the report using the technical name ORG. To translate program texts (RPT4), enter SAPLORG as the report name.
The client-dependency and delivery class of a table are relevant to table transports. The object type of a table therefore shows you if the table is client-specific or not. In the case of client-specific tables, the third letter in the object type ID is D. In the case of cross-client tables, the letter is I. The last letter in the four-character table shortcut is the delivery class of the table.
Example
You can directly access a client-specific system table using the shortcut TADS. A cross-client Customizing table, however, is accessed with the shortcut TAIC.
It is not always possible for translators to find out which R3TR transport object applies to a translation object, or which delivery class a table belongs to. For this reason, meta object types have been introduced to make it easier for translators to directly access subdivided object types. When these meta object types are used to access objects directly, the translation system finds the technically correct object type. The system has to search through all the subtypes, which means it takes longer to access objects with meta object types than with the technically correct object type ID. The following meta groupings exist:
Meta Object Type | Object Types |
CUA (user interface texts) | CA1, CA2, CA3, CA4, CA5, CA7 |
CUAD (developer interface documentation) | CAD1, CAD2, CAD3, CAD4, CAD5, CAD7 |
FSEL (field selection) | FEL1, FEL2, FEL3, FEL4 |
FUNC (function titles, parameters, exceptions) | FNC1, FNC2, FNC3 |
LIBT (function groups) | LBT1, LBT2, LBT3 |
REPT (text elements) | RPT1, RPT2, RPT3, RPT4, RPT6, RPT7, RPT8 |
SCRH (Screen Painter headers) | SRH1, SRH2, SRH3, SRH4, SRH8 |
SCRT (Screen Painter texts) | SRT1, SRT2, SRT3, SRT4, SRT8 |
SSCT (screen control) | SCT1, SCT2, SCT3, SCT4 |
TABL (tables) | TADA, TADC, TADW, TADE, TADG, TADS, TAIA, TAIC, TAIE, TAIG, TAIS, TAIW |
Technical Name
The way the technical name is formed differs from one object type to another. The following conventions exist:
<Technical name without prefixes or suffixes>
This applies to most object types, such as data elements, report texts, and domains.
<Technical name><blank characters><technical ID>
This applies to object types whose mere technical name is not unique. Examples include Screen Painter texts (screen number), message texts (message number), and cross-client tables including logical objects (table ID). The length of all keys is fixed, so blank characters are inserted between the technical name and the technical ID until the fixed key length has been reached. We recommend that you insert the blank characters by performing a placeholder search.
<Client><technical name><blank characters><technical ID>
This applies to client-specific tables. Once again, we recommend that you perform a placeholder search.
<Client><technical name>
This applies to other client-dependent objects, such as roles and forms.