Skip to Content

Logon Language, sy-langu, and RFC

In a recent discussion, Former Member pointed me to something that was not clear in my mind and therefore not made clear in the documentation (although one might have deduced it one or the other way).

It is about how the logon language of an RFC session is set.

First some clarification of terms:


  • The logon language is the language that is used as logon parameter when opening an user session on an AS ABAP. The logon language of an user session cannot be changed during the session. You can get it using  method GET_LOGON_LANGUAGE of class CL_ABAP_SYST.
  • An  internal session, that is a session inside a user session, where an ABAP program is executed, has  a text environment that is governed by a language. The text environment influences things like textual sorting of  internal tables. The language of the text environment can be found in sy-langu and you can get it from method GET_LANGUAGE of class CL_ABAP_SYST. When an internal session is started, the language of the text environment is the logon language. But you can change the language of the text environment using SET LOCALE LANGUAGE. After this statement, the language of the text environment and with it sy-langu can be different from the logon language. The change of the language of the text environment is valid within the current internal session only. Calling another program starts a new internal session with the logon language again.
  • An RFC session is a fully fledged user session that is opened when an RFM (remote function module) is called via the RFC interface. The logon parameters of the RFC session are either defined in SM59 for the RFC destination or passed implicitly. The latter is especially the case for predefined destination NONE and therefore also for CALL FUNCTION STARTING NEW TASK without specifying a destination.

How are the logon parameters of an RFC session set, that are not defined in the destination?


  • The username of the RFC session is the username of the calling session (sy-uname)
  • The client of the RFC session is the client of the calling session (sy-mandt)
  • The logon language of the RFC session is the language of the text environment of the calling session (sy-langu)

With other words, the logon language of the RFC session is not necessarily the logon language of the calling session (sy-langu is not necessarily the logon language)! You can use SET LOCALE LANGUAGE in the calling session to influence the logon language of the RFC session.



The function module is running in a fully fledged user session with logon language ‘E’. Everything that depends on the logon language, e.g. surface texts, text pools, formats, and of course the text environment again, is influenced by the language of the text environment of the caller.

E.g. if the RFM looks as follows:




The RFC opens SE38 in English, independent from the logon language of the caller. Note that placing SET LOCALE LANGUAGE directly in front of CALL TRANSACTION wouldn’t do the trick, because the call opens a new internal session.

Of course you can use SET LOCALE LANGUAGE in the RFM again in order to set the text environment of the internal session there.

PS: Reminder, don’t mix up SET LOCALE LANGUAGE with SET LANGUAGE. The latter does not set a language but loads the text pool of a given language.


You must be Logged on to comment or reply to a post.
  • I was watching that original discussion!!!! I had never really thought of that either…it was interesting. Glad you expanded upon it here in a blog rather than in a short questioner reply/comment that would likely get lost somewhere in the ether later.

  • Thanks Horst!

    The key takeaways for me are:

    – “logon language” and “text environment” are different things

    (I think I latently knew that)

    – “The logon language of the RFC session is the language of the text environment of the calling session (sy-langu)”

    -> good to know!



  • Hi Dr.Keller,

    One of my colleague encountered this scenario. The scenario was, a RFM was developed for UK store users and worked perfectly fine. But, when we rolled out the same for FR users, the messages was still appearing in English.

    The Frech users (FR) used the RFC with log-on language as FR. we tried this with SET LOCAL LANGUAGE, and noticed that, this statement worked only when the log-on language in SM59 is removed. otherwise, it by default takes the SM59 language set.

    Do we have any other work around for this scenario ?

    Thanks !

  • Dear All,

    thanks for sharing, but I still am puzzled.

    I want to call a standard report but with a different language (via submit ?). Is there another possibility?

    Any hints are appreciated.

    Best regards,

    Gotthard Friedrich

    • I have a report where you can call a transaction with a different language in the same session, not sure if that helps you….



      PARAMETERS tcode LIKE sy-tcode.
      IF tcode IS INITIAL.
      tcode = ‘SESSION_MANAGER’.
      tcode = tcode.

  • Hello Horst,

    Thank you very much for the article.

    My question is: what can I do if I have one field out of 10 in Hebrew, and 9 fields out of 10 in English?

    The Hebrew field I see as gibberish.

    Thanks in advance



      Hello Faina,

      1. Your question is not specific enough to give any answer.
      2. Rather place a question here