Most people familiar with "classic" SAP GUI logon would be aware of a language setting that triggers later messages and title text to be in that language, as long as the system is new enough to include that capability (before Unicode, things were, well, complex). If you are bilingual, or multilingual, there might be a reason for you to switch; perhaps you're working for a company based in North America that has staff that speak Spanish, or Portuguese.
As a developer, though, things are different. You may need to connect with the language you best understand in order to build out code and configurations. But you might need to enable multiple language texts for users. If your chiefs say "everyone uses English [insert any ISO here]" you're off the hook. But check this out anyway, in case your future is different than your now.
Let's say you have a team that populates message texts, and the developers' job ends at verifying that at least one or two locales work. Simple, relatively. But maybe your testing and verification rules say every locale must be tested in a least some percentage of the delivered scenarios (screens, reports, visualizations, etc.). If the translation team is capable of also running quality checks, great. If they have no authority to access some areas, there's a problem.
An enterprise scale production quality control process will have automated testing, perhaps several types, the more complex the landscape the more sophisticated the test harnesses. My experience was mainly with a scheduling package that could run batch jobs in SAP R/3 system(s). I managed to set up HANA system testing with the same scheduler, so my comments here are generalized to scriptable tests (typically kicking off ABAP jobs but any of the movable feast of APIs could and were leveraged, not to mention the (4GL) language of the day <cough, Perl>.
In the setup of an automated test user we assigned a classic Client ID, the typical account/password pair, and the logon language. While US-based Americas operations used English-only for batch work, European based teams required others. It was a limited set, e.g., there probably weren't any Lithuanian-specific test scripts. There might be a delimited list of allowed languages that correspond to what varieties the software delivery teams "own."
For other interfaces, whether JSON, GET, whatever, there may or may not be an equivalent logon language variable.
To figure out a good answer to today's question, I tried this search:
The question is from 2017, and had only 250 views recorded when I began to look at it. There will be more as some of you take a look, please, and perhaps one more astute than I in the area of " .xsodata services" can pitch in.