Subject: [scim] Multi-lingual support for some textual attributes

From: Andreas Åkre Solberg <[email-masked]>
Date: Mon, 28 Apr 2014 14:35:14 +0200

Hi folks, this is my first post, let me give a brief introduction:

I’m working with APIs for exchanging group information in federated environments, and work with a specification with the nickname “VOOT”. We are currently exploring the possibility to define this as a layer on top of SCIM. Although it looks very promosing, there is a number of minor issues that we need to resort in order to be fully compliant.

First out, given our European target community, the need for multi-lingual support is rather fundamental.

My assumption is that there is currently no multi-lingual support in SCIM?

Has this question been raised before, and if so any references?

If we would like to add attributes in multiple languages, it seems that complex attributes is the closest fit, but it does not feel compleley right either.

What do you think about introducing a new attribute type, translatableString which allows both plain backward-compatible representation of unspecified language:

{
    "displayName": "University X"
}
as well as one specific translation:

{
    "displayName": {
        "en": "University X"
    }
}
as well as multiple translations:

{
    "displayName": {
        "en": "University X",
        "no": "Universitet X"
    }
}
where the object properties used is defined by xml:lang.

It would also be nice to add support in the protocol for optionally flattening the translatableStrings in the response based upon HTTP content negotiation with Accept-Language.

In example like this:

GET /Resource/X?translate=1 HTTP/1.0
Accept-Language: no

{
    "displayName": "Universitet X"
}

-- 
Andreas Åkre Solberg
UNINET AS - http://uninett.no

---

From: Phil Hunt <[email-masked]>
Date: Mon, 28 Apr 2014 09:10:27 -0700

Andreas,

Your question is timely as I am just going through some of the internationalization support details for the next draft of core-schema.

I believe your question goes to the ability to have multiple translations (at the same time) for an attribute of a resource.

This was actually discussed (in Berlin?) at length and at the time there was no interest in this aspect of international support.

This view may be coming from LDAP hands where there was support but the feature was rarely used. Is this view still valid in the cloud?  The collective view at the time was it wasn’t needed. 

My major concern is that the solution would most likely require turning multi-lingual attributes into complex attributes (as you describe).  This makes the protocol significantly more complex.  Though that said, recent changes with the API draft now make this much easier to support since you can now update specific sub-attributes of complex attributes.

Could your case be handled using attribute extensions?  In this case the core schema value would be the default or preferred language of the user or the owner of the resource (e.g. group).  The extension would then contain the complex attribute structure you require. 

Do we need a multi-lingual attribute definition? —> so that at least multi-language attributes are handled consistently?

Phil

@independentid
www.independentid.com
[email-masked]

On Apr 28, 2014, at 5:35 AM, Andreas Åkre Solberg <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: David Möbius <[email-masked]>
Date: Tue, 29 Apr 2014 11:42:47 +0200

Hi Andreas,

I also think this looks very much like an case for extension. I think
you have to look which fields need to be multi language and store the
translation in the extensions.
If you are exploring the possibility of scim at the moment and working
with Java maybe our schim schema could help for you to have minimal
effort. With the scim schema we already have an easy possibility to
store and to retrieve scim extensions.
With the scim schema we are implementing a OpenSource scim 2.0 project.
Together with the other OSIAM projects (Server, connector4Java and
selfadministration) we have a framework that could help you to have an
quick start.
In about 2 weeks we will also go to version 1.0

scim schema: https://github.com/osiam/scim-schema
osiam main: https://github.com/osiam

If you have more question about this please contact me.

by David

Am 28.04.2014 18:10, schrieb Phil Hunt:
> Andreas,
> 
> Your question is timely as I am just going through some of the
> internationalization support details for the next draft of core-schema.
> 
> I believe your question goes to the ability to have multiple
> translations (at the same time) for an attribute of a resource.
> 
> This was actually discussed (in Berlin?) at length and at the time there
> was no interest in this aspect of international support.
> 
> This view may be coming from LDAP hands where there was support but the
> feature was rarely used. Is this view still valid in the cloud?  The
> collective view at the time was it wasn’t needed. 
> 
> My major concern is that the solution would most likely require turning
> multi-lingual attributes into complex attributes (as you describe).
>  This makes the protocol significantly more complex.  Though that said,
> recent changes with the API draft now make this much easier to support
> since you can now update specific sub-attributes of complex attributes.
> 
> Could your case be handled using attribute extensions?  In this case the
> core schema value would be the default or preferred language of the user
> or the owner of the resource (e.g. group).  The extension would then
> contain the complex attribute structure you require. 
> 
> Do we need a multi-lingual attribute definition? —> so that at least
> multi-language attributes are handled consistently?
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> On Apr 28, 2014, at 5:35 AM, Andreas Åkre Solberg
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> I’m working with APIs for exchanging group information in federated
>> environments, and work with a specification with the nickname “VOOT”.
>> We are currently exploring the possibility to define this as a layer
>> on top of SCIM. Although it looks very promosing, there is a number of
>> minor issues that we need to resort in order to be fully /compliant/.
>>
>> First out, given our European target community, the need for
>> multi-lingual support is rather fundamental.
>>
>> *My assumption is that there is currently no multi-lingual support in
>> SCIM?*
>>
>> If we would like to add attributes in multiple languages, it seems
>> that /complex/ attributes is the closest fit, but it does not feel
>> compleley right either.
>>
>> What do you think about introducing a new attribute type,
>> |translatableString| which allows both plain backward-compatible
>> representation of unspecified language:
>>
>> |{
>> |
>> |{
>> |
>> |{
>> |
>> where the object properties used is defined by |xml:lang|.
>>
>> It would also be nice to add support in the protocol for optionally
>> /flattening/ the |translatableString|s in the response based upon HTTP
>> content negotiation with |Accept-Language|.
>>
>> In example like this:
>>
>> |GET /Resource/X?translate=1 HTTP/1.0
>> Accept-Language: no
>>
>> {
>> |
>> [email-masked] <mailto:[email-masked]>