Returning localized taxonomy field value labels (GetListItems)...

[jar240]

Hi Marc.

I have a list. The list has a managed metadata field. the associated termset's terms all have French labels added, in addition to English. The farm has the French language pack installed (on top of the default English), and an alternate language has been enabled (French, FR-fr) on the site collection.

If I switch languages in the UI (MUI), the taxonomy field values (labels) in the lists switch. If I get the data via SPServices, I only get the English values (labels).

Let's say I have the following two terms (and labels):
"For Sale": "For Sale" (EN), "A vendre" (FR)
"Wanted": "Wanted" (EN), "Demande" (FR)

After some experimentation using SOAP-UI, I discovered that if I add the _"Accept-Language" header _with a value of "fr-fr", I will get the French label in the taxaonmy Field's value! Ex "12;#A Vendre", which is what I'm after.

If I call GetListItems without an_ "Accept-Language" header_, I get "12;#For Sale" for the field value.

Perfect!

Is there a way for me to pass this custom header value into my SPServices call? I don't want to edit the SPServices JS file itself. I'd also not have to hook into the XHR directly to add the header if at all possible.

(FYI the hidden Note Field attached to the Taxonomy field only returns the English label for both calls, but that's ok.)

Thanks,
Chris

[sympmarc]

I assume that was your tweet I just replied to? Did you try passing in the lcid, or are you not calling the TaxonomyClientService?

[jar240]

I'm talking about calling GetListItems via SPServices, not calling the Taxonomy Service itself. Getting field values, not the available labels. I'm able to get all the terms and labels (for the pick list).

[jar240]

I'm very surprised the lists.asmx is that smart!

var resultPromise = $().SPServices({
    operation: "GetListItems",
    ...,
    customHeaders: [['Accept-Language','fr-fr']];   <--- something like this?
    debug: false //true
});

How can I add the "Accept-Language" custom header to the underlying XHR call?

[sympmarc]

I've never seen SOAP-UI before - looks really useful.

It doesn't look like I've left any hook to pass customHeaders into a request using SPServices. This might make a nice little enhancement. I'm surprised it's never come up before.

[jar240]

I'm curious as to whether or not the SP 2013/2016 REST API behaves in the same way, or if they've accounted for language in the API contract itself.

Do you have a future SPServices release planned?

[sympmarc]

I do have a future release planned, but I keep getting busy and not getting to it. I'm looking at the core to see how I can allow you to pass in custom headers. It doesn't seem that difficult.

[purtuga]

FYI...
jQuery .ajax allows for "global" events on ajax requests... You can can turn that on (if currently off) and then add an event that will alter the request prior to sending it to the server.. the event yo want is ajaxSend: http://api.jquery.com/ajaxSend/

More about global ajax events: http://api.jquery.com/category/ajax/global-ajax-event-handlers/
I use them for capturing network request for debugging purposes.

/Paul

[sympmarc]

I've just added a customHeaders option to core so that you can pass in any arbitrary name/value pairs. See headers here.

I'm pushing a new set of changes now. It includes a shift to gulp and webpack, and you should be able to build your own version.

Right now the syntax is:

$().SPServices({
  operation: "GetListItems",
  listName: "States",
  customHeaders: {'Accept-Language':'fr-fr', "boo": "foo"}
});

See if that does what you want.

Note that this is an early v2.0 build, but it's coming into focus.

[jar240]

@purtuga Thanks, that's what I'm working on. Seems this goes much deeper though!

While adding the "Accept-Language" header works from outside the browser (.Net code, PowerShell client, SOAP-UI), it doesn't from within (JavaScript). Something else is being sent in the xhr that's causing sharePoint to ignore that header value.

I'm strongly suspecting the 'lcid' cookie is the culprit. If this turns out to be the case, achieving what I want is going to be trickier. :-(

[sympmarc]

Well, we have the customHeaders capability built into SPServices now, should it ever become useful.