[OASIS Issue Tracker] (CAMP-190) Localization/Customization of Attribute Definition and Type Definition names

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/CAMP-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62191#comment-62191 ] 

Anish Karmarkar commented on CAMP-190:
--------------------------------------

There two issues here: localization of the attribute names and localization of attribute values (esp. for read-only values like "name"). This is useful in the context of building the right UI.

For the attribute values, HTTP content negotiation header (Accept-Lanugauge) should be sufficient for the provider to send a response back in the appropriate language.

For attribute names, three possible solutions some to mind:
1) Use Accept-Language HTTP header and let the provider decide what is appropriate to send back. In this case, it is the provider the decides the appropriate translation.
2) This is a general problem and there are solutions being devised for this. Eg: http://www.localeplanet.com/api/translate.html http://blog.mozilla.org/webdev/2011/10/06/i18njs-internationalize-your-javascript-with-a-little-help-from-json-and-the-server/
In this case, it is the local client that decides how to translate names.
3) Optionally allow providers to include a pointer (or inlined) in the attribute definition for translations. In this case, the provider decides on the translation.
For example a new optional attribute call 'translation' in the attribute definition { ..., "translation": {"en": "hello", "fr": "bon jour"}, ...}

> Localization/Customization of Attribute Definition and Type Definition names
> ----------------------------------------------------------------------------
>
>                 Key: CAMP-190
>                 URL: https://issues.oasis-open.org/browse/CAMP-190
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>    Affects Versions: 1.2
>            Reporter: Michael Norman
>            Assignee: Michael Norman
>            Priority: Minor
>
> The Attribute Definitions and the Type Definitions seem to link their names to the name of the resource/attribute in the spec (although this is only clear to me for the attribute definition). However there may be a requirement for a different name to be used in the User Interface as a less formal word to describe the attribute or resource, and indeed to deal with localization. It would be useful for there to be two names in these resources, one which is linked to the resource/attribute and one which is both user-mutable and locale-specific (e.g. it may be possible for an implementation to issue different values based on http request header localization).



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)