Duplication of search categories names in two files

[pastk]

At the moment search categories localized names are taken from data/strings/strings.txt, e.g. [eat] definition for "Where to eat".

At the same time search synonyms for those categories are defined in data/categories.txt, e.g. in @ear supercategory.

The problem is that the name from strings.txt must be present amongst synonyms in categories.txt, otherwise category search won't work, hence its easy to break it when e.g. someone updates translations in strings.txt.

One approach to solve it is to refactor the code so that category names are not taken from strings.txt, but a first synonym from categories.txt is used instead.

Another, more radical approach, is to get rid of special categories.txt format and merge it into types_strings.txt (see #1644 (comment)).

Original discussions (in Russian): #1830 and #1834

[biodranik]

Moving the current categories.txt parser into twine (to support strings.txt format) may not be worth it. But properly implementing two things can make the life of everyone easier:

1. Add a method to get the first translated category synonym from the C++ core and use it in iOS and Android (e.g. GetSearchCategoryTranslation("@eat"). Then there will be no duplication.
2. Search engine also matches types translations from strings.txt if they are referenced in categories.txt. Categories.txt references searchable types and optionally adds some search synonyms.

A more radical approach could be to move translations of all types into the categories.txt file, and somehow mark searchable/not searchable types there. That approach also avoids duplication and makes it easier to remember the default type translation for synonyms.

[pastk]

A more radical approach could be to move translations of all types into the categories.txt file, and somehow mark searchable/not searchable types there. That approach also avoids duplication and makes it easier to remember the default type translation for synonyms.

This idea is similar to merging categories.txt into types_strings.txt. But we'll end up with two distinct file formats to support still whereas we can rule them all with just one :)