Character Notification endpoint needs to display humanized msg.

[c0dezer019]

Feature Request

This template contains an example feature request. Please replace all text except for the checklist and the section headers (they start with #). Thank you for your contribution to improving ESI.

Please provide a short description of your feature request here. E.g.:

War against Corp A declared by Corp B has been inherited by Corp C.

is far more readable than

againstID: 123455667\nallianceID: 12343322\ndeclaredByID: 123434523\nopponentID: 12232132\nquitterID: 12331334\n

Use case

Who would be the primary consumers of this feature? E.g.:
Everyone that uses the notification endpoints (like EveMon)

Players that want to view in-game notifications while offline and recruiters and human resource reps from the larger orgs.

Authentication

Does this feature require a new scope, an existing scope, or no scope? E.g.:

Would use the read_notification route auth, as it currently does.

Example return

Propose what an example return might look like. E.g.:

[
  {
    "notification_id": 1234565678,
    "sender_id": 12345667788,
    "sender_type": "alliance",
    "msg": "Thor's Love Palace (Fortizar) in J123445 has self-destructed.",
    "text": "solarSystemID: 111111111\nstructureTypeID: 11111\n",
    "timestamp": "2022-09-08T13:30:00Z",
    "type": "SovStructureSelfDestructFinished"
  },
]

Checklist

Check all boxes that apply to this issue:

• Feature request description is provided
• Use case exists
• Feature requires a new route
• Feature adds data to existing route
• Feature requires new auth scope
• Feature can reuse existing scope
• Feature does not require auth
• Meta feature, applies to all routes

[wfjsw]

You can always generate a readable description as you like by parsing the notification payload? Parsing it server-side would dramatically increase the load since it would query databases more and many consumers are polling that.

[cvweiss]

APIs are meant to be consumed by computers and then formatted for human presentation depending on the criteria.

I propose closing this issue.

[evanova]

This would require rather complex localization from ESI side to support multiple languages. While the notification format is not great, it does its job and the abstraction using notification codes is just fine. User friendly strings don't fit well.

[c0dezer019]

This would require rather complex localization from ESI side to support multiple languages. While the notification format is not great, it does its job and the abstraction using notification codes is just fine. User friendly strings don't fit well.

It would not. The app developer can translate it themselves on their end as there are plenty of i18n libraries out there.

[NathenSample]

As has been said the API endpoints are designed for machine consumption not human consumption - As a general rule of thumb CCP avoid "pre-cooking" their data, and instead expect you to make use of either other endpoints, or the SDE when building human readable strings.

I'll be closing this for now.