translations.txt: translation should not be a primary key

[timMillet]

Current issue

The primary key for translations.txt is *, meaning all fields are part of the primary key. However, this allows two identical records to be translated in different ways for one language, with no reasoning behind which translation should take precedence. It seems that this is in fact an error, and that the translation field should not be part of the primary key of the table. Example:

routes.txt

route_id,route_short_name
route_id_1,subway

translations.txt

table_name,field_name,language,translation,record_id,record_sub_id,field_value
routes,route_short_name,fr,métro,route_id_1,,
routes,route_short_name,fr,train,route_id_1,,

Solution in this PR

The fields (table_name, field_name, language, record_id, record_sub_id, field_value) are the primary keys of translations.txt.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

For more information, open the CLA check for this pull request.

[westontrillium]

Would my solution to #327 negate the need for this change?

[timMillet]

@westontrillium IMHO, no, the issue would remain.

[timMillet]

It looks like the proposal does not raise any other concerns. I’m opening a vote on this PR.

• translations.txt is already produced and consumed (see the original PR#180). Transit is interested in consuming it once this PR is accepted.
• Voting ends on 2022-06-02 at 23:59:59 UTC.

NB: The vote is also open on PR#327 which fixes another issue in translations.txt.

[skinkie]

+1 OpenGeo, thanks for the fix.

[npaun]

+1 Transit

[brodyFlannigan]

+1 Brody Flannigan Transit Data

[botanize]

+1 Metro Transit

[flocsy]

+1 Moovit

[timMillet]

The voting period has ended. With 5 votes in favor and no votes against, this proposal is adopted.
Thanks to anyone who participated and voted!