Refactor Localized String into its own type in gbfs.md

[bdferris-v2]

In PR #460, the new text localization change introduced a {"text": "blah", "language": "en"} object for representing localized text within a single feed file. As a practical matter, the definition of the text and language fields was repeated for each localized string element in gbfs.md.

As discussed at the time, I suggested it would be nice to consolidate all those entries into a single type that is defined once and reference that type instead. That idea had some support, but we agreed it could wait as it could be done as an editorial change that did not change the semantics of the spec itself.

Now that PR #481 has gone in, which included usage of Array<Type> syntax, I'd like to follow that pattern for Localized String as well. This PR proposes that change. It is purely a documentation change and does not add, remove, or change the semantics of any fields.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

All files with localized strings.

[bdferris-v2]

@testower and @mplsmitch just a heads-up. As previously discussed, I opened this PR to refactor how localized strings are documented in the spec (does not change the schema or semantics of the spec itself). Per guidance from @josee-sabourin, I will probably open this for a vote on Monday, but wanted to give you advance warning in case you had any concerns.

[mplsmitch]

@bdferris-v2 No concerns for me. One thing I think would help this PR is to add a second language to one of the JSON examples where the localized string type is used. Maybe in system_information.json.

[testower]

Looks great - thanks for doing this @bdferris-v2 🎉

[bdferris-v2]

I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on Friday, March 31, 2023.

Please vote for or against the proposal, and include the organization for which you are voting in your comment.

[cmonagle]

+1 on behalf of Transit.

Thanks @bdferris-v2 !

[testower]

+1 from Entur

[benwedge]

+1 from Joyride

[josee-sabourin]

This vote has now closed, and it passes!

Votes in favor:
Transit (consumer)
Entur (consumer)
Joyride (producer)


There were no votes against.

Since does not modify any functionalities of the spec, it will be rolled into v3.0-RC