[mythtv] Multiple simultaneous language support

[Chris Hamilton]

First off, I'll introduce myself as a relatively long-time Myth user (3
years), and a big fan of the project.  I haven't been very active on the
development side of things, mostly working on local hacks, having only
contributed back a single patch. I'd like to change that, and get a
little more involved in the project.

Many people in North America and in Europe simultaneously receive
programming in multiple languages (in my case, I regularly watch both
English and French programming).  MythTV is already quite well
internationalized, but it currently works in a single chosen language at
a time. I'd like to see MythTV, specifically the program listings, work
a little more smoothly with multiple simultaneous languages.

Some of the things I'd like to see:
* language specific handling of prefixes when using the Program Finder
* filtering listings based on program language (in normal guide, Program
Finder screen, etc)

As a first step to doing this, it would effectively be necessary to add
a 'language' field to the 'program' table, likely just a ISO 639-2 three
letter language code. Here's how I envision this working:

(ASIDE: Maybe separate 'description_language' and 'program_language'
fields? Does this ever happen, where the description/title has come down
in one language, but the program is in another?)

* All sources of guide data populate this field if they are sure
(mythfilldb, EIT parser, etc). If a guide source is unsure, then the
field is left null.
* Potentially a machine learning classifier for unclassified programs.
Something like this might be relatively computationally expensive, but
could be run as a background task.  Ideally, the classifier would only
label program it was 'sure' about in some statistical sense.
* Finally, configurable default values.  For simplicity I would envision
just defaulting to some global default language (the same as the
language used in the interface?), but maybe a per 'chanid' over-ride?

So, basically I'm just looking for comments and maybe suggestions.  I
realize that such a fix is likely to impact a large variety of places in
the code and thus the scope is relatively large.  Does this sound like a
reasonable undertaking?

Cheers,

Chris