Internationalization of free-form text descriptions

[EdouardBavoux]

There are some free-form text descriptions specified in the GBFS (example : cross_street field in station_information.json). I think it would be great to have the possibility to describe these fields in various languages. So far, I think the only way to do so would be to publish/import different sets of GBFS files for different languages (which is heavy, and adds a risk of conflict between the sets of files.)
Did you consider this possibility already ? Thanks,
Edouard

[barbeau]

@EdouardBavoux The format of translations in GBFS surprised me too. As it shows in https://github.com/NABSA/gbfs/blob/master/gbfs.md#gbfsjson, you duplicate all the files to have different languages:

{
  "last_updated": 1434054678,
  "ttl": 0,
  "version": "2.0",
  "data": {
    "en": {
      "feeds": [
        {
          "name": "system_information",
          "url": "https://www.example.com/gbfs/1/en/system_information"
        },
        {
          "name": "station_information",
          "url": "https://www.example.com/gbfs/1/en/station_information"
        }
      ]
    },
    "fr" : {
      "feeds": [
        {
          "name": "system_information",
          "url": "https://www.example.com/gbfs/1/fr/system_information"
        },
        {
          "name": "station_information",
          "url": "https://www.example.com/gbfs/1/fr/station_information"
        }
      ]
    }
  }
}

I'm curious if anyone knows the rationale behind this original design decision, and if others feel like having a more lightweight translation mechanism would be helpful.

[mplsmitch]

I don't recall exactly how this was arrived at but at the time there were multiple providers who were already publishing feeds in this way. I think we probably just went along with what was already the established practice.

…

On Wed, Sep 2, 2020 at 8:29 AM Sean Barbeau ***@***.***> wrote: @EdouardBavoux <https://github.com/EdouardBavoux> The format of translations in GBFS surprised me too. As it shows in https://github.com/NABSA/gbfs/blob/master/gbfs.md#gbfsjson, you duplicate all the files to have different languages: { "last_updated": 1434054678, "ttl": 0, "version": "2.0", "data": { "en": { "feeds": [ { "name": "system_information", "url": "https://www.example.com/gbfs/1/en/system_information" }, { "name": "station_information", "url": "https://www.example.com/gbfs/1/en/station_information" } ] }, "fr" : { "feeds": [ { "name": "system_information", "url": "https://www.example.com/gbfs/1/fr/system_information" }, { "name": "station_information", "url": "https://www.example.com/gbfs/1/fr/station_information" } ] } } } I'm curious if anyone knows the rationale behind this original design decision, and if others feel like having a more lightweight translation mechanism would be helpful. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUHWFLHIUG27UGSZD2XXZTSDZCEPANCNFSM4QSVNO5Q> .

-- Mitch Vars | en | Senior Data Modeler | MobilityData IO | mobilitydata.org mitch@mobilitydata.org | +1 612 788 7627 | Minneapolis, Minnesota, USA

[barbeau]

Just to give an example of an alternate translation design, GTFS-realtime uses a single file for data in all languages (so non-human readable things like booleans and integers aren't duplicated), but for each human-readable field in Alerts it includes two values: the language code and the translation for each language.

The end result looks something like this:

 alert {
    "active_period": {
      "start": 1284457468,
      "end": 1284468072
    },
    ...
     "description": [
        {
          "text": "The Elm street the stop is closed.",
          "language": "en"
        }, {
          "text": "L'arrêt de la rue Elm est fermé.",
          "language": "fr"
        }
      ]
  }

[EdouardBavoux]

@barbeau : That's definitely a better approach for translations, indeed.

[stale]

This disucssion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days if no further activity occurs. Thank you for your contributions.

[stale]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.

[testower]

Is there any chance that this will be considered for 3.x @mplsmitch ?

[mplsmitch]

@testower we've got this on our roadmap for Q3 this year so if we're able to pass something it would go in 3.x

[mplsmitch]

I'd like to reopen this discussion - it was closed by the StaleBot. No additional work has been done on this issue. Is this something we should be looking at for v3.0?