Keep all translations in OKAPI

[following5]

OKAPI currently reads translations for country names, language names [with #570] and waypoint types from OC database. But OCPL plans to remove translations from the database, and anyway it's better if OKAPI returns consistent texts for all OC sites (including OCDE sites).

So I suggest to add all these translations to Okapi. If a country or language or wp-type name translation would be completely missing, we could just fall back to the code or type-id, and send email to Okapi developers.

The country and language names can be extracted from Wikipedia.

[kojoty]

From our (OCPL) point of view translations phrases in DB are difficult in maintenance. We would like to be sure what translations are supported based on code not on DB which can be different between nodes and local dev. setups.

[following5]

OCDE has all master translations in files, but copies them to the database with each code deployment. So they are both in Git and in the database and always identical everywhere.

(The same is done with triggers & stored procedures, and all other static stuff in the database.)

[kojoty]

OCDE has all master translations in files, but copies them to the database with each code deployment. So they are both in Git and in the database and always identical everywhere.

Got it. I'm interesting if they are any pros of having translations in DB and maintaining it on that way? Why not just read from files? Or maybe it was done because of compatibility with OCPL-code running nodes?

[following5]

Probably it's just another way of doing the same thing. OCDE will e.g. join the cache_types table to the translations table on trans_id, retrieving a list of cache types including translated names via SQL. OCPL will just obtain the IDs and then fetch translations in a PHP loop.