convert terms back to array on transifex import [Suggestion]

[westnordost]

I think it would be a slight improvement from a data structure point of view to convert the terms back from a comma separated string to an array already during the import from transifex.
So, the actual iD code does not convert it back but it is already in the right form to consume. Also, it is more consistent to have the terms as an array in the localization files because it is also an array in the presets.json. (Was confused about this)

What do you think?

The localizations need to be re-generated if this is merged.

[manfredbrandl]

As a translator I would prefer to split up the terms before the transfer to transifex and MAYBE do allow only one translation requirement per unique term.

[westnordost]

@manfredbrandl Did you read the readme for translation contributions? It states

The translations for presets consist of the names of presets, labels for preset fields, and lists of search terms. You do not need to translate the search terms literally -- use a set of synonyms and related terms appropriate to the target language, separated by commas.

In other words, search terms are not to be translated literally. Instead, the search terms should be a list of words in the target language with which that preset should be searchable.
It may also well be, that there are no eligible terms in the target language while there are in English, or the other way round.

[manfredbrandl]

@westnordost Danke, das habe ich nicht richtig gelesen.

[bhousel]

I think I'd prefer for all of the data in the translation files to just be strings.

I know that the terms eventually need to be an array, but ultimately it's strings that get translated into other strings.

(also, doing it this way in update_locales.js would leave the en.json terms as strings, so that's a problem)

I'm going to close because it doesn't actually solve a real problem that we have right now, but I agree we should think about better ways to handle the terms that go to Transifex.