Add rt alerts guidance

docs/en/resources/mobilitydata-recommendations/gtfs-realtime-service-alerts/guidelines.md

@@ -123,7 +123,7 @@ Bad example (MBTA): The alert mentions all needed information in the header and
 "headerText": {
  "translation": [
    { 
-     `"text": "Haverhill Line Train 1231 (10:25 am from North Station) is operating 10-20 minutes behind schedule between North Station and Reading due to a signal issue.",
+     "text": "Haverhill Line Train 1231 (10:25 am from North Station) is operating 10-20 minutes behind schedule between North Station and Reading due to a signal issue.",
      "language": "en"
    }
  ]
@@ -141,7 +141,7 @@ Bad example (MBTA): The alert mentions all needed information in the header and
 ## URL
 
 * Make sure the URL directs to a page that details the alert or contains information directly related to it. For example, the URL directs to a page containing illustrations of a detour or a moved stop.  
-* ِAvoid generic URLs or URLs that direct to pages where the user has to navigate further to find details about the alert.
+* Avoid generic URLs or URLs that direct to pages where the user has to navigate further to find details about the alert.
 
 ## Image (Experimental)
 

docs/en/resources/mobilitydata-recommendations/gtfs-realtime-service-alerts/real-life-examples.md

@@ -7,8 +7,8 @@ In this example, we present examples of Service Alerts that were created for rea
 Published on 28-03-2025
 
 * The header is badly formatted. It seems to continue into the description.   
-* The header should be modified to “Line 1 Yonge-University: No service between St George and St Andrew”.  
-* The description should be finished: “Service will resume…”  
+* The header should be modified to "Line 1 Yonge-University: No service between St George and St Andrew".  
+* The description should be finished: "Service will resume…"  
 * The effect should be modified to `MODIFIED_SERVICE`.  
   * Do not set `NO_SERVICE` as this effect is currently generally concerned with stop and platform closures. In this case, it seems like the trip is effectively split in the middle into two separate trips.  
 * The cause should be modified to `MAINTENANCE`.  
@@ -172,7 +172,7 @@ Published on 28-03-2025
 
 Published on 28-03-2025
 
-* The header should be expanded: “No service in the Cowichan Valley due to Labour action.”   
+* The header should be expanded: "No service in the Cowichan Valley due to Labour action."   
 * The cause should be modified to `STRIKE`.  
 * The effect should be modified to `NO_SERVICE`.  
 * The URL mentioned in the description should be included in the `url` field.
@@ -266,7 +266,7 @@ Published on 28-03-2025
        }  
      ]  
    },  
-	“url”: “https://www.bctransit.com/cowichan-valley”,  
+	"url": "https://www.bctransit.com/cowichan-valley",  
  }  
 }  
 ```
@@ -609,12 +609,12 @@ Published on 02-04-2025
 
 Published on 02-04-2025
 
-* The header is much longer than the description. The second part of the header “ \- use the stops on Lexington Ave at E 53rd St or E 41st St instead” can be transferred to the description.  
-* The `stop_id` for Lexington Ave at E 46th St should be added to each entity in informed entities, to specify that the alert is only applied to the affected routes at the “Lexington Ave at E 46th St “ stop only. If the affected routes are the only routes that use that stop, then the `route_ids` are not necessary to include.  
+* The header is much longer than the description. The second part of the header " \- use the stops on Lexington Ave at E 53rd St or E 41st St instead" can be transferred to the description.  
+* The `stop_id` for Lexington Ave at E 46th St should be added to each entity in informed entities, to specify that the alert is only applied to the affected routes at the "Lexington Ave at E 46th St " stop only. If the affected routes are the only routes that use that stop, then the `route_ids` are not necessary to include.  
 * The cause should be added as `CONSTRUCTION`.  
 * The effect should be added as `NO_SERVICE`.  
-* HTML entities like “\</b\>” should be replaced with plain text alternatives.  
-* The “en-html” translation should be removed.
+* HTML entities like "\</b\>" should be replaced with plain text alternatives.  
+* The "en-html" translation should be removed.
 * The fields `communication_period` and `impact_period` should be used instead of `active_period`.
 
 ```  
@@ -672,8 +672,8 @@ Published on 02-04-2025
 * The effect should be modified to `ACCESSIBILITY_ISSUE`.  
 * The cause should be modified to `MAINTENANCE` or `CONSTRUCTION`.  
 * In `informed_entity`, the `stop_id` for the \[7\] platform should be mentioned, the station as well.  
-* “accessibility icon” should be removed, and HTML entities like “\&nbsp;” should be replaced with plain text alternatives.  
-* The “en-html” translation should be removed.
+* "accessibility icon" should be removed, and HTML entities like "\&nbsp;" should be replaced with plain text alternatives.  
+* The "en-html" translation should be removed.
 * The fields `communication_period` and `impact_period` should be used instead of `active_period`.
 
 ```  

docs/en/resources/mobilitydata-recommendations/gtfs-realtime-service-alerts/real-world-use-cases.md

@@ -29,11 +29,11 @@ Suggestions:
 * If `tripUpdates` are provided, change `ScheduleRelationship` in the `TripDescriptor` of the affected trips to CANCELED if possible.  
 * If there is any replacement service and it is possible to create, then you can either:  
     * Create it in the GTFS Schedule feed if the closure is planned or once it extends over time and you have more certainty around the closure.  
-    * If that replacement service corresponds to a route in the GTFS and you cannot define the additional trips in the GTFS Schedule feed, then create it in `tripUpdates` with the `TripDescriptor \= NEW`.
+    * If that replacement service corresponds to a route in the GTFS and you cannot define the additional trips in the GTFS Schedule feed, then create it in `tripUpdates` with the `TripDescriptor = NEW`.
 
 !!! Note "Suggested template"
 
-    Header: “ Service interrupted on route `{route name}`”
+    Header: “Service interrupted on route `{route name}`”
 
     Description: “Due to {cause}, service is suspended on route/line `{route name}` from`{start time}` to `{end time if applicable}`. Please use `{replacement suggestion}` instead.”
 
@@ -72,7 +72,7 @@ Suggestions:
 
 !!! Note "Suggested template"
 
-    Header: “ Trips cancelled on route `{route name}`”
+    Header: “Trips cancelled on route `{route name}`”
 
     Description: “Due to {cause}, a few trips are cancelled on `{direction}` route/line `{route name}`. The current trips are affected `{human-readable trip identifier, e.g. start time}`. Please use `{replacement suggestion}` instead.”
 
@@ -142,8 +142,8 @@ Suggestions:
     * The time period(s) that the service disruption spans (in the description, can be also additionally included in the header if it doesn’t make the header overlong).
 
 * If `tripUpdates` are provided, change ScheduleRelationship in the `StopTimeUpdate` of affected `stop_times` to SKIPPED if possible.  
-* Remove the `stop_id` from the stop time entries in `[stop_times.txt](https://gtfs.org/documentation/schedule/reference/#stop_timestxt)` for trips that serve the closed stop. This is more important if the alert extends over time (weeks to months).  
-* If it is certain that the stop is going to be permanently closed, remove it from the GTFS Schedule feed. Otherwise, you do not need to remove the stop from `[stops.txt](https://gtfs.org/documentation/schedule/reference/#stopstxt)`. 
+* Remove the `stop_id` from the stop time entries in [`stop_times.txt`](https://gtfs.org/documentation/schedule/reference/#stop_timestxt) for trips that serve the closed stop. This is more important if the alert extends over time (weeks to months).  
+* If it is certain that the stop is going to be permanently closed, remove it from the GTFS Schedule feed. Otherwise, you do not need to remove the stop from [`stops.txt`](https://gtfs.org/documentation/schedule/reference/#stopstxt). 
 
 !!! Note "Suggested template"
 
@@ -175,8 +175,8 @@ Suggestions:
     * The time period(s) that the service disruption spans (in the description, can be also additionally included in the header if it doesn’t make the header overlong).
 
 * If `tripUpdates` are provided, change `ScheduleRelationship` in the `StopTimeUpdate` of affected `stop_times` to SKIPPED if possible.  
-* Remove the `stop_ids` of the station platforms from the stop time entries in `[stop_times.txt](https://gtfs.org/documentation/schedule/reference/#stop_timestxt)` for trips that serve the closed station. This is more important if the incident extends over time (weeks to months).  
-* If it is certain that the station is going to be permanently closed, remove it and its child stops from the GTFS Schedule feed. Otherwise, you do not need to remove the station and its stops from `[stops.txt](https://gtfs.org/documentation/schedule/reference/#stopstxt)`.
+* Remove the `stop_ids` of the station platforms from the stop time entries in [`stop_times.txt`](https://gtfs.org/documentation/schedule/reference/#stop_timestxt) for trips that serve the closed station. This is more important if the incident extends over time (weeks to months).  
+* If it is certain that the station is going to be permanently closed, remove it and its child stops from the GTFS Schedule feed. Otherwise, you do not need to remove the station and its stops from [`stops.txt`](https://gtfs.org/documentation/schedule/reference/#stopstxt).
 
 !!! Note "Suggested template"
 
@@ -289,7 +289,7 @@ Suggestions:
     * The time period(s) that the service change spans (in the description, can be also additionally included in the header if it doesn’t make the header overlong).
 
 * The alert might exist even when the stop was changed in the GTFS Schedule feed. (Just for informative reasons; could lead to mismatch issues as no `stop_id` in GTFS).  
-* If the alert is planned or extends over time (weeks to months), consider updating `stops.txt` and `[stop_times.txt](https://gtfs.org/documentation/schedule/reference/#stop_timestxt)` to reflect the new stop.
+* If the alert is planned or extends over time (weeks to months), consider updating [`stops.txt`](https://gtfs.org/documentation/schedule/reference/#stopstxt) and [`stop_times.txt`](https://gtfs.org/documentation/schedule/reference/#stop_timestxt) to reflect the new stop.
 
 !!! Note "Suggested template"
 
@@ -310,7 +310,7 @@ Suggestions:
 * In `tripUpdates`, make sure that the `StopTimeUpdate` of affected `stop_times` is adjusted.  
 * Insignificant delays should be in `tripUpdates`, do not create an alert.
 
-  ---
+---
 
 ## Strong Delays
 
@@ -339,7 +339,7 @@ Suggestions:
 
 !!! Note "Suggested template"
 
-    Header: “ Delayed service on route `{route name}`”
+    Header: “Delayed service on route `{route name}`”
 
     Description: “Due to {cause}, route/line `{route name}` is experiencing delays up to `{estimated current delay}`.”
 
@@ -370,7 +370,7 @@ Suggestions:
 
 !!! Note "Suggested template"
 
-    Header: “ Schedule adjustment for `{route names} from `{start time}` to {end time if applicable}`”
+    Header: “Schedule adjustment for `{route names} from `{start time}` to {end time if applicable}`”
 
     Description: “Due to {cause: new service, short term change}, service is adjusted for `{routes names}` from `{start time}` to {end time if applicable}. Please refer to our website `{URL (also included in the URL field)}` for further details.”
 
@@ -410,7 +410,7 @@ Suggestions:
 
 !!! Note "Suggested template"
 
-    Header: “ More trips running for `{route names}`”
+    Header: “More trips running for `{route names}`”
 
     Description: “Due to `{cause: new service, short term change}`, more departures will run for `{routes names}` starting `{start time}` until `{end time if applicable}`. Please refer to our website `{URL (also included in the URL field)}` for further details.”
 
@@ -445,7 +445,7 @@ Suggestions:
 
 !!! Note "Suggested template"
 
-    Header: “ Fewer trips running for `{route names}`”
+    Header: “Fewer trips running for `{route names}`”
 
     Description: “Due to {cause: new service, short term change}, fewer departures will run for `{routes names}` starting `{start time}` until {end time if applicable}. Please refer to our website `{URL (also included in the URL field)}` for further details.”
 
@@ -491,6 +491,6 @@ Suggestions:
 
 !!! Note "Suggested template"
 
-    Header: “ `{route names}`: The vehicle on {human-readable trip identifier. e.g. trip start time} is not accessible”
+    Header: “`{route names}`: The vehicle on {human-readable trip identifier. e.g. trip start time} is not accessible”
 
     Description: “Due to `{cause: e.g. mechanical error}`, the vehicle operating under `{route names}` on the trip `{human-readable trip identifier}` is not  accessible.”