Open cobaltpet opened 6 years ago
This problem seems insurmountable. For some of the "A" entries, I can use the macro language entries. But some EiBi language codes represent "languages of (country)" or language-inspecific Vatican programming, and those are unmappable. And Amoy, Amoy Hokkien, or Xiamenese is missing from ISO 639-3.
Entries that lack a direct mapping can be worked around with a made-up code and simply passed through, but then searchability is based on a made-up value and I don't like that solution.
Note about hard-to-resolve cases: the main requirement is to be consistent. Ensure no data is lost when converting from EiBi to ISO 639-3 to human-readable. For languages that don't map to ISO 639-3, create a made-up code such as eibi-xyz with the understanding that it can be improved later if necessary.
When importing a shortwave schedule data set, convert the broadcast language(s) to the intermediate format ISO 639-3 (https://en.wikipedia.org/wiki/List_of_ISO_639-3_codes) in BroadcastEntry objects. Require those language codes when filtering by language with the
-l
option. Convert those codes to human-readable strings (in English, to start, as this script is not internationalized or localized yet) at schedule display time.So for example, when importing an EiBi schedule,
CA -> yue -> Cantonese E -> eng -> English