translations.txt support

112 views
Skip to first unread message

Nikhil VJ

unread,
Mar 28, 2018, 11:48:58 PM3/28/18
to Transit Developers
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

unread,
Apr 10, 2019, 10:22:34 PM4/10/19
to Transit Developers
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:

- 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

unread,
Jun 19, 2019, 8:10:19 AM6/19/19
to Transit Developers
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

unread,
Jun 22, 2019, 12:10:28 AM6/22/19
to Transit Developers
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
Reply all
Reply to author
Forward
0 new messages