translations.txt support

[Nikhil VJ]

Hi,

Google transit's extensions to GTFS, features a translations.txt file that I found quite useful:
https://developers.google.com/transit/gtfs/reference/gtfs-extensions#translations

So I am making it and putting it in my GTFS feed. But all the GTFS validators I've tried are flagging it as warning.

I suppose it's because the spec probably came along after the last update to the validator project.

I found this feature request for the same from 2015: https://github.com/google/transitfeed/issues/407

I would like to try code-contributing for this, but presently don't know where to begin. Any guidance would be appreciated. The help text of feedvalidator.py shows this:

--extension=EXTENSION
                        the name of the Python module that containts a GTFS
                        extension that is to be loaded and used while
                        validating the specified feed.

Also, is there any other validator that does accept translations.txt ? And otherwise, how can I test it or see it at work?

[Nikhil VJ]

Hello,

Resurrecting an older post with something else but the subject-line applies.

I found a new program in the transitfeed suite : upgrade_translations.py

From there I found out that a new format for translations.txt has been adopted:

- https://developers.google.com/transit/gtfs/reference/gtfs-extensions#gtfs-translations

- http://bit.ly/gtfs-translations (links to a google doc)

I'm going through the new specs laid out, but am not able to understand it clearly. Got lost from "record_id" onwards.

It would really help to see an example of what a translations.txt table would look like as per these specs. If anyone has a file along these specs, please share.. just a couple of rows shared would help a lot.

Also, I'm not able to find discussion about it here or in the transitfeed issues section. Is there some other group to look up?

Regards

Nikhil VJ

Pune, India

[Alexej Ababilov]

Hi Nikhil,

Here is a sample for you.

table_name,field_name,language,translation,record_id,record_sub_id,field_value

stops,stop_name,es,Puerto,SeaPort,,

trips,trip_headsign,es,Estanque,,,Pond

The first line translates stop_name for a stop that has stop_id=SeaPort.

The second line translates trip_headsign for all trips that have trip_headsign=Pond.

Feel free to ask more questions in that mailing thread.

Alexej Ababilov

[Nikhil VJ]

Hi Alexej,

Thanks, this makes a lot more sense now. Examples are so much better to learn from.

Trying to put this logic forth in my own words:

First row: Irrespective of what it's called in other languages, the Spanish stop_name for stop_id=SeaPort is "Puerto".

Second row: Any trip_headsign that says "Pond" is to be translated to "Estanque" in Spanish.

I can understand why it was needed to shift to this from the earlier model where it was a universal Find+Replace. We might want to keep "Pond" as "Pond" in some places and only translate to "Estanque" in specific places. On my end it's mostly just stop_name values needing translation, so the model of the first row suits.

Cheers

Nikhil VJ, Pune, India