Proposal Pool
Purpose
The proposal pool is a database in which source texts are stored together with their translations for short texts (that is, texts less than 255 characters long that are translated in the short text editor).
For example, the German source text Vorgang and all its English translations constitute one entry in the proposal pool for source language German and target language English. Each English translation of the source text Vorgang is called a proposal.
A separate proposal pool exists for each source and target language combination translated in the system. These proposal pools are initially empty. You create proposals as you translate in the short text editor, which builds up the proposal pool. These proposals save you time when you translate more texts later.
The proposal pool has the following functions:
· The best proposal is displayed underneath the translation line in the short text editor, which means the source text does not need to be translated manually. You can double-click the best proposal to copy it to the translation line, instead of typing the translation manually again.
The helps to ensure that source texts are translated consistently, resulting in a higher level of quality for your language versions.
· Pinpoints source texts that have been changed by a developer.
For example, you have translated the source text Sichern as Save, and you have created this translation as a proposal in the proposal pool. The developer changes the source text Sichern to Drucken (the proposal Print already exists in the proposal pool for this source text.) Your translation Save no longer matches the best proposal Print, so the source text has the status modified. You need to adapt the translation of the source text.
· Enables corrections to be made quickly and simply
If you need to change a frequently used translation, but cannot remember which individual objects contain this translation, you can change the translation in the proposal pool. After the next evaluation run, all of the text lines in which this translation is still used have the status modified because the old translation does not match the new proposal in the proposal pool. You do not need to access the objects containing these modified lines individually. You can translate them in your personal worklist instead.
·
After you have
translated a certain number of short texts and created proposals for them in
the proposal pool, you can translate source texts automatically by using
automatic
distribution. If this function has been set up in a translation system,
proposals for certain source texts can be inserted automatically into the
translation line and then saved.
It is also possible
to
transport proposal
pools from one translation system to another. You can then use your proposals
in the other translation system, which helps to ensure that translations
remain consistent in all systems.
You only need to maintain the proposal pool if you intend to use its functions. If all you need to do is enter a translation, you can simply save it in the short text editor.
Integration
The proposal pool interacts with the following functions in the translation environment:
When you translate short texts in the short text editor, the system displays the best proposal for each source text for which proposals already exist. You can then copy the best proposal to your translation line, simply by double-clicking it.
When you translate source texts for which no proposals exist yet, you can branch to the proposal pool to create your translation as a proposal. The source text then has the status translated, and you can reuse the proposal whenever you have to translate the same source text again. If automatic distribution is active in your translation system and the proposal you created satisfies the criteria defined for distribution, you may never have to translate this source text manually again!
When an evaluation runs in the system, each translation is compared with the proposal pool entries for the source text in question. If the translation does not match a valid proposal, the system assigns status modified to the source text. If the translation matches a valid proposal, the system assigns status translated to the source text.
·
SAPterm
When translating terminology in SAPterm (transaction STERM), you can refer to the proposal pool to ensure that the terminology in the terminology database is consistent with the terminology in the proposal pool.
You can also access the proposal pool directly via transaction SLPP, where you can:
· Use the proposal pool as a reference
You can refer to the proposal pool when translating text types other than short texts (for example, when translating menu paths in long texts, or training materials.) This enables you to find out how a specific source text is translated in the system, for example.
· Maintain proposals
You can create and delete proposals in the proposal pool via transaction SLPP.
For more information, see Transaction SLPP.
Features
Structure of the Proposal Pool
You often require more than one translation for a source text.
For example, the German term Beschaffung is best translated as Procurement in the area of Logistics, but in the area of Human Resources, the best translation is Recruitment.
For this reason, the proposal pool structure in ABAP systems mirrors the first level of applications in the component hierarchy. For example, it contains the following nodes: BC (Basis), CA (Cross-Application Components), LO (Logistics - General), and PY (Payroll.) However, subnodes such as BC-DWB and LO-LIS are not available. It is entirely feasible for the translation environment to be used for developments that are not ABAP-based, which cannot be assigned to the ABAP component hierarchy. For this reason, the terminology areas derived from the component hierarchy are known as domains.
The domain-based structure of the proposal pool enables you to create domain-specific proposals that are only valid within the domains for which they were created.
Each translated object belongs to a collection. The collection is a unit of developed objects or files. In ABAP systems, a collection is usually a package. Each collection is assigned to a domain. This domain is used to determine the domain in the proposal pool for which you can define an application standard when translating an object from the collection.
You should always check the domain of each short text object you translate. The domain is displayed in the title bar of the short text editor. Example:
ACGR (PA) From deDE To enUS: SAP_HR_PA_SPECIALIST
When translating the object in the short text editor, the title shows you that you can create domain-specific proposals for the domain PA (Personnel Management.) When the system determines the best proposal, it notes that you are currently translating in the domain PA.
You can, of course, create proposals for any object that are valid throughout the entire system (that is, proposals that are valid for all domains, regardless of the object you are currently translating.) These proposals are called system standards.
If you want to create an application standard in the proposal pool for a domain other than the domain of the object you are currently translating, choose the Show Domain icon.
Translations are stored in the proposal pool as follows:
If you want your translation to be valid throughout the system, create a system standard. The system standard is valid in all domains for which an application standard does not exist. The system standard is the best proposal in all domains without an application standard.
If you only want your translation to be valid in the domain of the object you are currently translating, create an application standard. Application standards are only valid in the domain for which you created them. However, it takes priority over the system standard, which means it is the best proposal when you translate objects from this domain. You cannot translate a source text with the system standard if an application standard exists for the domain of the object you are currently translating.
You create an exception if you only want your translation to be valid in the domain of the object you are currently translating, and do not want to impose this translation on the entire domain.
Exceptions are domain-specific, and they are never the best proposal. You can translate a source text with the system standard if an exception exists for the domain of the object you are currently translating.
You need to create an abbreviation if you do not have enough space in the translation line for the full text of the translation you want to use. For example: you want to translate the source text Vorgang as Transaction, but the translation line is only seven characters long.
Abbreviations are assigned to their full translations in the proposal pool (the full translation is the translation you would have used if the translation line were long enough.) You can create abbreviations for system standards and application standards, but not for exceptions. An abbreviation should always be the same translation as the full translation. For example: you must never define Process as an abbreviation of Transaction.
See also:
Creating Proposals in the Proposal Pool