Localization for format application/geo+json when calling https://api.weather.gov/alerts/active

[jmarks213]

The original CAP specification includes support for localization which appears to be missing from the application/geo+json format (or no one is currently publishing es-US?).

Is anyone able to clarify if localization is expected to be returned? Seems as if each feature of the featurecollection should potentially return multiple properties but properties is not currently defined as an array.

[dwhitemv25]

Looking through the schema, it does not appear the GeoJSON or JSON-LD outputs support multiple languages. The language value is in the <info> tag of the CAP alert, so the entire JSON alert would have to be instanced to provide the translated versions.

If you request the cap+xml format, you will get the localized versions, if they were sent in the original alert. For example, alert ID urn:oid:2.49.0.1.840.0.5d160f7bad96f26afcf6f327ad21ed4c8be875ec.001.1 has both en-US and es-US versions in the XML output. Note that in that alert the only localized content is the CMAM (Mobile Alert) strings.

It would be nice if the API supported the Accept-Language header to select which language version is returned.

Going through my CAP archive, I only see Tornado Warning and Flash Flood Warning sent with multiple languages, though my archive only holds the last week or so of alerts.

[jmarks213]

If you request the cap+xml format, you will get the localized versions, if they were sent in the original alert. For example, alert ID urn:oid:2.49.0.1.840.0.5d160f7bad96f26afcf6f327ad21ed4c8be875ec.001.1 has both en-US and es-US versions in the XML output. Note that in that alert the only localized content is the CMAM (Mobile Alert) strings.

Attempting to use application/cap+xml with the newer api ( https://api.weather.gov/alerts/active ) is only returning the application/geo-json on my end. Which end point are you requesting the cap+xml from that still includes localization?

[dwhitemv25]

Looks like you can only request the "localized" CAP message for a specific alert using the /alerts/{id} endpoint. The aggregated XML format for /alerts/active et. al. is application/atom+xml, but it flattens the CAP alert and in the process loses the <language> tag. (Might be a problem with the ATOM format not supporting multiple languages either? Research needed.)

Using my example, if you fetch the individual alert with Accept: application/cap+xml you'll see there are two <info> blocks, each with a different <language>.

I guess you have to iterate through the {id}s you get from active, request each alert individually, then check if they have multiple <info> blocks.

Again, you might monitor what you get back and see if the localization is helpful for you. Are you just extracting the WEA text messages? That's the only localized part I can see in the alerts I have archived.

[jmarks213]

Using my example, if you fetch the individual alert with Accept: application/cap+xml you'll see there are two <info> blocks, each with a different <language>.

Ah, yes I see what you refer.

Hmm I am not sure you can even call the es-US block a Spanish translation. Surely the headline, description, and instruction blocks should be directly translated. I do see that the Spanish translation for headline is nested in the parameter CMAMtext and the instruction in the CMAMlongtext to go with the wireless emergency alert. It seems a hack to assume the CMAMtext is always going to be the headline and the CMAMlongtext is going to be the instruction.

I will reconsider supporting localization at all for now. Thank you for the assist