DRAFT: Full translation implementation

[kylerchin]

This is a collaborative effort between the Rust-Transit Maintainers and the Catenary Transit Initiatives https://catenarymaps.org team, a nonprofit designing open-source public transport software. We seek comments from the community and maintainers.

Team members responsible: @CallMeJai @AndrewHC36 @kylerchin Thank you to @Robbe7730 for the original idea of RawTranslations

THIS IS A WORK IN PROGRESS DRAFT AND WILL BE UNMARKED ONCE READY

This discussion originated at https://github.com/orgs/catenarytransit/discussions/2

Key points of discussion:

• How to cleanup code converting field_name to enum
• Trait implementation from @Tristramg
• Utility summary tables included

Final notes: Note that as GTFS is an evolving specification, the contents of the translatable field will change over time.

[kylerchin]

Documentation will be added once everything is set!

Thank you to Andrew especially for spending hours with me to whiteboard out data structures and coming up with an implementation.

Attached is our whiteboard understanding and possible data structure examples of implementation:

[kylerchin]

Should we keep the HashMap like this? Or should we use the trait system? or both? What direction should the lookup mechanism take?

I personally would be alright with the current structure and a trait lookup mechanism, providing options would make the library more friendly for developers.

[andrew-shc]

I was thinking for the TranslationsLookup, embed the record id and record sub id type into the field names enum directly to reduce invalid usage, and so the user knows whether this field just needs a record id or also with a record sub id.

Refer to the record_sub_id’s requirement in description, though they point out agencies can add additional fields that might invalidate the specified requirements.

[kylerchin]

We plan on implementing traits properly in a bit