Update translations.txt after Fares v2 addition into GTFS

[isabelle-dr]

Describe the problem

translations.txt is a GTFS file that allows producers that operate in regions that have multiple official languages to provide translations to user-facing names.
Several features of the GTFS Fares v2 extension project have been adopted in GTFS recently, and some of them apply to the scope of translations.txt.

Use cases

Allowing to match the fare product name and potentially the fare media name to the names used by the agency rider-facing information, in places where several official languages exist.

Proposed solution

Extend the translations.txt file with:

• fare_product_name: The name of the fare product as displayed to riders.
• fare_media_name: Name of the fare media (e. g. Clipper card).

We need a producer and a consumer to be able to adopt this in GTFS. If you are either and you're interested in supporting this, please comment on this issue or write us at specification@mobilitydata.org.

Additional information

First GH issue opened with the new template 🏄, this is great!

[github-actions]

This issue has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

[BodoMinea]

We have started producing translated fare_product_name and fare_media_name fields for our Bucharest - TPBI feed which recently got Fares v2 support.

However, it can not be included in our main-line production feed at this time since it causes the following error in the MobilityData validator:

Which in turn causes the Google Transit import pipeline to fail on Google's end, and therefore our feed not to be published for use by riders:

I believe this error is a false positive, since fare_products and fare_media should not need record_sub_id as they have a unique ID / primary key.

For now we have set up a separate URL that serves the version of the feed with translated Fares v2 which you can access here http://gtfs.tpbi.ro/regional/BUCHAREST-REGION_translated_fares.zip or download as an attachment here - BUCHAREST-REGION_translated_fares.zip (this URL is NOT expected to be permanent).

We'd be happy for any consumers to ingest this for testing and getting it adopted as part of the spec (I suppose that would also trigger the necessary actions to properly define fare-related structures as part of foreign key checks inside the validator, which seems to be what is failing now).

[skalexch]

@BodoMinea thank you for sharing this example and for working on Fares v2 for TPBI!

I took a look at the GTFS and the validator code. The first record of the missing_required_field notice is row 8, so the error is only generated for fare products.

This is the code that verifies record_id and record_sub_id. Basically, it takes the column names of the primary key of the table to be translated. If the length of that entire key is more than 1 (for record_id only) or 2 (for record_sub_id) it raises the notice, regardless of the values of those keys.

There is definitely a case to improve this behaviour by additionally checking if we can have one unique value by using what the translations.txt table has, ie:

• If other primary key columns are empty; in this case rider_category_id.
• Or if the record_id simply has different names. In this case, using fare_product_id is sufficient to differentiate different fare products.

In this context, @isabelle-dr @tzujenchanmbd we should also think about how to deal with fare products having 3 columns in its primary key (after the adoption of rider categories). That will only allow for matching fare products for translations based on the value of the fare_product_name field itself, we cannot effectively do it using record_id and record_sub_id.