T002 table — T002 Language Key table

One row in T002 represents one language key recognized by the system, for example E for English, D for German, F for French, or J for Japanese. The table is the value list behind the SPRAS domain, which is used as a key field on virtually every language-dependent table in the system, from message text tables to short text tables for repository objects. T002 itself does not carry translated text; it only declares which one-character (and in extended Unicode systems, longer) language codes are considered valid and installed. It is client-independent, so the same list applies across every client in the system. Whether a given language is actually usable for logon, for translation work, or for text maintenance depends on separate language installation and configuration steps, not on a row existing here.

T002 is a reference list, not a transactional table, so the joins that matter run from language-dependent tables back into it. The pattern is always the same: a text or description table carries SPRAS as part of its key, and that value is expected to exist in T002. Typical checks look like T100-SPRAS = T002-SPRAS for message texts, TSTCT-SPRAS = T002-SPRAS for transaction short texts, DD04T-SPRAS = T002-SPRAS for data element and field label texts, and DD07T-SPRAS = T002-SPRAS for domain fixed value texts. Long text objects stored through SAPscript or text tables such as STXH also carry a language field checked the same way. In practice nobody writes an explicit inner join to T002 in a report; it is used as a foreign key check target during data entry and as a value help list in configuration screens.

The table is tiny, client-independent, and fully buffered, so there is no real selectivity concern. Selecting the full table is normal and cheap. The only thing worth restricting on is SPRAS itself when checking whether a specific language is present, and the field is case-sensitive for the one-character codes. Because it is client-independent, do not expect client-specific differences; if a language is missing, it is missing everywhere, and installing it in one client makes it available system-wide.

Suspected cause: a user reports the logon language dropdown or a text field shows no entry for a given language, for example Portuguese. Select T002 with SPRAS = P. If no row comes back, the language has not been installed or activated on the system, and the fix is a language installation and supplementation step, not a text translation task. If the row exists, the problem is downstream in the specific text table for that object, not in the language master list.

T002 continues to exist unchanged in S/4HANA as the client-independent language key list; there has been no structural redesign of this table and no compatibility view has replaced it, since it is a simple reference list rather than a business or Customizing table. Language installation and supplementation processes around it remain conceptually the same, though the tooling used to manage languages has evolved over releases.

Basis owns language installation, supplementation, and the content of T002 itself. Application consultants and translators own the texts inside the language-dependent tables that reference SPRAS. When a translation is missing, check with the module team responsible for that text object before escalating to Basis, since the language key itself is very rarely the actual gap.

Language-dependent tables that carry SPRAS and check against T002 include T100 for message short texts, TSTCT for transaction short texts, DD04T for data element and field labels, DD07T for domain fixed value texts, and text objects stored through STXH and STXL for long texts. None of these are maintained by directly editing T002; language content is populated through translation tools, language transport, and standard configuration transactions for each object type.