change language in gateway

[Former Member]

I have a gateway service, when execute the URL, getting values in English language. is there any way we can change the language into ES?

[former_member265047]

Hi Mathew,

I hope your oData service being called though GW system alias and that alias being linked with RFC destination. So can you keep the language field is blank in RFC destination, then it would take the language from Portal logon language or browser language i guess. I have tested from Portal application & it worked fine. Hence you can try this option and see whether it works or not.

Regards,

Naveen Veshala

[hschaefer123]

Hi Folks,

since 2013 are ther any news on this topic?

We are currently also developing apps, that run in the context of an "hard" setted user inside SICF to avoid Login for company internal used sites.

In our former solution (custom service implementation) we were able to change language via header or also via GET param sap-language=fr.

Such a szenario show the problems of the GW i18n behavior on first Login!

SAPUI5 uses the prefered browser settings for language, but it is also quite comfortable to

be able to switch the language via GET param. UI5 supports this out-of-the-box!

Our E-Commer Apps behave the same way, where you can quickly switch between languages in case of customer support without the need to change your login language!

Any change to get this into a future service patch.

Best regards,

Holger Schäfer

[former_member226070]

Hi we added the parameter  sap-language  in the JSON call.

Regards,

Jeroen

[Andre_Fischer]

Hi Jeroen,

adding our sap proprietary URL parameter sap-language will probably work but please have in mind that it can also cause confusion.

If you have configured English as your language in your browser and would call a html5 app that runs in a portal where the app would use the parameter with sap-language='DE' than the portal pages will show up in English while only your app will show up in German.

Just my 2 cents.

Best regards,

Andre

[Former Member]

Hi all,

I'm resurfacing this post because none of the stated language options seem to have any effect.

1 - sap-language does not change the value of sy-langu. I never thought it did anyway, yet people are saying it works for them.

2 - Accept-header does not work. It does not change sy-langu. I have debugged this and the language is extracted from this header at one point in ABAP but never used. The headers are placed in a context object  that cannot be seen by the DPC access methods when language dependency values might be needed for a query.  If this value were available as part of the technical request I could use it.

For me, this matter is still far from clear - how do we reliably detect language?

FYI this has come about from a separate investigation into the use of etags, and the fact that if.match headers, etc do not appear to be transferred from requests either, despite there being some handler logic.

Regards

Ron.

[RalfHandl]

The Accept-Language header is evaluated when processing the first request in a logon session. The determined language is then stored in the session cookie and retrieved from there, so to switch language mid-session requires to suppress sending that cookie. This "optimization" is done on a layer below Gateway.

So you can switch the language, but it's not as easy as it could be.

Regards

-- Ralf

[Former Member]

Hey Ralf,

What I am inferring from your response is that the initial logon determines the language because the language is always obtained from the cookie stored against that initial contact.

Having accepted that I'll have to work with HTTP headers to get my language preferences understood, I now find it is further hampered by cookies, which are a component more relevant to browsers than the HTTP abstract.

It seems to me that this is a "limitation" of the SAP ICF and the current SAP OData framework, not OData itself. There appears to be an imposed rule in ICF that says the only accepted language is the first one detected at login, which contravenes my interpretation of all OData requests being able to change language at will by altering the accept-language header.

Technically, there should be nothing stopping the backend from being able to detect the requested language of a request. The value is present in the request data that is initially available in the request handler. It is subsequently descoped and not visible to the extraction logic.

What I would like to see is the language value(s) from accept-language included in the technical request object that currently exposes the OData elements of the request.

To wrap-up for now , part of the OData committees driving goals for V4 was to reduce the number of ways of doing the same thing. Currently we are managing language changes in a myriad of ways because we have no consistent means of doing so - we need a common touchpoint.

Regards

Ron.

[RalfHandl]

Hi Ron,

Excellent summary.

Step 1 to a consistent language handling was to state the desired behavior in the OData specification.

Step 2 will be to implement it in our OData stacks.

I like your proposal for making the requested language vector available in the technical request object, and have put it on our discussion list. Let's see what results from that discussion.

Thanks!

--Ralf

[Former Member]

Hello Ralf,

I am struggling with similar issues.

The web application sends the Accept-Language header correctly. This goes to a Gateway system and the header is set on a request context. However, this header is not transferred to the Backend system (Hub Architecture). Which means, the actual data provider is not able to retrieve the texts in the correct language as the language handover does not take place. Do you have any insights?

Any help here is greatly appreciated!

Thanks

Neha

[Andre_Fischer]

Hi Thomaskutty,

you should check the language settings of your browser.

The logon language is per default retrieved via the HTTP Accept-Language header .

In addition the language in question (here ES) would have to be installed as a logon language in your GW hub system and in the backend system if you run a hub based installation.

You can check the status of the installed languages using the report  RSCPINST.

Best Regards,

Andre

[Former Member]

Hi Andre,

Is the use of HTTP Accept Language header a workaround?

I am aware that the OData specification (<= V.3) seems to have missed some important I18N features.  If language dependency is in there I can't find it.

The use of headers is covered in the OData spec but not this one, so it seems like a SAP-specific solution (workaround) rather than fundamental OData (which is fair enough if OData has no functionality to cover it).

I understand your point about HTML-embedding (sort-of) but isn't an important point of OData that it separates the data from the UI constraints? As such I find things getting a bit SOAP-y when there are more headers than anything else

Regards

Ron.

[RalfHandl]

Hi Ron,

Language negotiation with the Accept-Language header in requests and Content-Language header in responses is a core feature of HTTP (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4), and OData builds on HTTP, so it intentionally doesn't define anything proprietary for it.

Unfortunately the authors of OData <= 3.0 forgot to mention that this HTTP feature naturally can be used with OData. An omission that I now can understand, being a co-author of the OData 4.0 specifications who also forgot to mentioned Accept-Language explicitly I'll check whether I still can fix that omission, but we are near the end of the specification process, so making changes is getting harder every day.

What we did explicitly mention in the OData 4.0 specifications is that responses (and their ETags) can be language-dependent, and we define a Core annotation that services can use to make clients aware of language-dependent content:

        <Property Name="Description" Type="Edm.String">

          <Annotation Term="Core.IsLanguageDependent" />

        </Property>

Accept-Language is the preferred way for language negotiation in OData, and our OData-enabled products support it.

Hope this helps!

--Ralf

[Former Member]

Thanks for clearing that up Ralf.

Whilst I agree that OData is built on HTTP and that does have support for indicating language, I would really expect OData - as a protocol - to have some intrinsic means of specifying language.

Once we start expecting the users of OData to start delving into the HTTP layer for what is a basic requirement, it starts to dilute the benefits of a common protocol. The headers will start to become a covert channel for all kinds of sub protocols

Header values are required in (SAP) OData, I know, but they tend to relate to technical aspects such as CSRF tokens. I consider something like language to be more in the sematic domain and therefore surfaced up to the metadata level (as you have started to do with the V.4 isLanguageDependent).

I am looking at this from a best practice angle for OData, agnostic of HTTP features and as an OData "customer". In that regard I would not consider the use of an HTTP header to be a good practice, even if it is completely "legal".

Should/could we not have a short optional modifier that can be passed in the URL in the same way that the versioning modifier is sent? Or even a "$language" query option? Someone reading a protocol specification will find that nice and quickly!

Regards

Ron.

[RalfHandl]

Hi Ron,

OData builds on HTTP, so it cannot be agnostic of HTTP. It also does not want to reinvent things that have worked well in HTTP for decades. It uses content negotiation with the Accept and Content-Type headers, and it also uses language negotiation with the Accept-Language and Content-Language headers.

We already point that out for the media type, and forgot to point that out for the language. Thanks for catching that!

I'm trying to fix this now, see https://tools.oasis-open.org/issues/browse/ODATA-553, so readers of the next published version of the protocol specification will find these headers listed in chapter 8, along with the other HTTP standard headers that play a crucial role for OData.

Thanks!

--Ralf

[Former Member]

Hi Ralf,

A slight misunderstanding, I meant that I am agnostic of HTTP, not that OData is agnostic

The point being, that although I am a developer, I do not know the full breadth of HTTP and would like (what I consider) mainstream topics such as language dependency to be fully managed within the context of the current protocol, not the one that underpins it.

I'll also point out that a SAP mentor colleague of mine, who I consider well versed in HTTP, had no idea about this language feature either.

I think it will put a lot of people off if they start thinking that they need to be HTTP experts as well.

OData is generating interest outside of developer circles. If I had a business designer creating and documenting a Gateway model and he asked how he would might get a product text feed in French, that designer is going to glaze over when I start talking about HTTP headers . However, if I could point him to a language-related function that is part of the OData specification and documentation, it would be much more acceptable as it's part of the same protocol.

Sorry if I seem to be dragging this out but an important point for me is that we have an opportunity to demystify web services, which would be helped by having as few "skeletons in cupboards" as possible.

Thanks for taking the trouble to include some of this into the latest documentation.

Regards

Ron.  

[RalfHandl]

Hi Ron,

Apparently the word "agnostic" touched a point that is still sore from too much SOAP

It's no trouble, on the contrary: we're trying hard to make the OData 4.0 specs as readable and self-contained as possible, and explicitly listing those standard HTTP headers that are especially important for OData absolutely makes sense.

If you've come across other areas where we could be more explicit, please contact me!

Thanks in advance!

--Ralf

[Former Member]

Hello Thomaskutty, please refer to below document

http://scn.sap.com/community/developer-center/netweaver-gateway/blog

Hope this will be helpful to you.

Kind Regards.

[Andre_Fischer]

Hi George,

Adding the parameter sap-language to change the language is not something I would recommend to use for an application when being used productively.

Reason is that the language of the logged on user is taken from the HTTP Accept-Language header by the framework.

Using the parameter sap-language might lead to unwanted results if you integrate a HTML based application into another Web page.

While the Web page will show results based on the HTTP Accept-Language header (for example in English) only the HTML5 based app would show results in Spanish.

The parameter is however a great help for developers that want to test their applications in different languages because changing the logon language this way is much faster than changing the default language of your browser.

Best Regards,

Andre

[Former Member]

Hi Andre

Have a nice day~

I really appreciate your kind advice  I will reference it in the future.

Best Regards.

George