ui: Add German category translations used by tv_grab_eu_epgdata for icons.

[azlm8t]

Add icon mappings for category names used by "tv_grab_eu_epgdata", as given in sample file in bug 5359.

(This doesn't fix that bug, it just adds icons from the xml file).

[perexg]

I think that it may be better to use only one language for the category names and translate names to the local language using gettext. So, import -> english names -> webui -> international translation.

[perexg]

In other words - the mapping should be done in the xmltv importer.

[azlm8t]

I've been thinking about it, but I have two concerns.

One concern with translating the strings at server-side is that traditionally, "gettext" uses English as the input, and we'd be feeding it xmltv category words such as the French word "Météo", to get the English word "Weather". I'm not sure if the system can handle that or if it will believe that "Météo" is the English translation.

We'd probably have to tvh_gettext in the htsp server too because a French xmltv supplying French category of "Météo" would internally get translated at xmltv import to the English word "Weather", and we then need to re-convert it at the htsp_server back to "Météo" or "Previsiones meteorológicas", etc. But, as you say, at the web UI we would send the English word "Weather" so we could lookup the icon and then translate the word there to the locale.

My other concern is that the potential categories are unbounded/unknown. So, although my SchedulesDirect has a category of "Comedy drama", "Pursuit" and "Animal's Perspective"(!), other grabber's probably don't.

So, although I agree I18n would be good, I'm not sure if doing partial-I18n (such as top ten categories we know exist) will lead to endless bug reports asking for one more word to be translated? Looking at my recent xmltv files, I have 3365 unique categories and I can imagine bugs saying that category X isn't translated to language Y on the Kodi frontend.

In the UI we only map a handful of keywords. But I agree it's really not satisfactory having the logic there as-is for making it easy for non-programmers to add translations we can then use in the UI.