Closed karlitschek closed 8 years ago
The name
property is limited to plain text without markup but both the content
and summary
property value contain HTML markup.
{
"nameMap": {
"en": "My Album",
"es": "Mi album"
},
"summaryMap": {
"en": "<b>This</b> <i>is</i> <u>my</u> Album!",
"es": "<b>Este</b> <i>es</i> <u>mi</u> álbum"
}
}
The name
/nameMap
property is intended to provide a short plain text, natural language name for the object that is suitable to display in a broad range of ways, including when html markup is not appropriate (simple lists for instance). The summary
/summaryMap
/content
/contentMap
properties are really intended to provide the rich content you're looking to express.
"summaryMap": { "en": "This is my Album!", "es": "Este es mi álbum" }
thinking about a large system which supports a hugh number of languages it is quite a waste of network and cpu to generate these messages for e.g. 50 languages where in most cases only one if required.
Is it reasonable to add http accept language support to the specs? https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4
THX
Well, AS2 is a format while http accept language is a protocol concern. It is perfectly acceptable for your API implementation to use accept language to negotiate a specific language version of the AS2 content.
Please Indicate One:
Please Describe the Issue: We try to do an implementation for ownCloud but we have a question how markup and translation should work. Translations loose the opportunity to highlight/markup things: https://www.w3.org/TR/activitystreams-core/#example-3 "nameMap": { "en": "Martin added a new image to his album.", "ga": "Martin phost le fisean nua a albam." }, nameMap is the multi-lang version of name: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-name
This means we loose the in-line links, avatars, highlight of parameters,
What is the recommendation here or do we miss something?
@nickvergessen @DeepDiver1975