Skip to Content
Author's profile photo Horst Keller

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.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Christopher Solomon
      Christopher Solomon

      I was watching that original discussion!!!! I had never really thought of that 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.

      Author's profile photo Joachim Rees
      Joachim Rees

      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!



      Author's profile photo Former Member
      Former Member

      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 !

      Author's profile photo Horst Keller
      Horst Keller
      Blog Post Author

      SET LOCALE sets the logon language only if it is no set in SM59. I see no workaround for that.


      Author's profile photo Gotthard Friedrich
      Gotthard Friedrich

      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

      Author's profile photo Thorsten Watzke
      Thorsten Watzke

      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.

      Author's profile photo Vishal B
      Vishal B

      Hello Thorsten Watzke,

      My code is same as u mentioned above, the only change is that I cannot use 'STARTING NEW TASK' Since  this does not work with NWBC it only works for GUI.
      Now the issue without using 'STARTING NEW TASK' is that the language is updated for the 1st time as per SET LOCALE LANGUAGE LANGUAGE. But when I run the piece of code again it will not update the language, it will still have same language set during 1st run for the 2nd tcode.

      Can you suggest anything for this issue.


      Author's profile photo Kiran K
      Kiran K

      Thanks for sharing the info.


      Author's profile photo Dominik Kramer
      Dominik Kramer

      Hello Horst,

      Thank you very much for the article.

      It helped me enhance an already 15 year running application.

      Kind regards.

      Author's profile photo Faina Fridman
      Faina Fridman

      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


      Author's profile photo Horst Keller
      Horst Keller
      Blog Post Author


      Hello Faina,

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


      Author's profile photo Mario Kopp
      Mario Kopp

      Hello Horst,

      one additional question to this Topic. We call a RFC from our central ATC System in an own implemented Check where we fetch Description of Reports. This is an existing SAP Function Module which is RFC enabled.

      In this Function Module there is at the End an SELECT against the TRDIRT with Reportname and Language. The Language will we selected with SY-LANGU (FM Name : SIW_RFC_READ_TRDIRT). Because the Description is maintained sometimes in German and sometimes in Englisch. we first try to call the RFC via English and then via German if nothing found in English.

      The Problem is that we use before the RFC call the command SET LOCALE LANGUAGE ‘D’ and when we enter the other System you can see in the Debugger that SY_LANGU is switched again back to ‘E’ immeaditely.

      We have checked the RFC Connection in SM59 and there is no Language Default stored there.

      What is going wrong ?

      Best regards


      Author's profile photo Shai Sinai
      Shai Sinai

      A useful tip regarding the RFC function call.

      I wonder why there isn't any standard way to set the language permanently for the whole user session (and not just the internal session).

      Calling SUBMIT via RFC isn't an ideal solution because it has its own disadvantages (a new user session with its own memory area, for example).

      Author's profile photo Vishal B
      Vishal B

      Hello Horst Keller,

      I am facing similar issue with set logon language.
      The problem is I am unable to update the language  second time can you please suggest some solution for this.