a handful of small mistakes were made in "simplifying" the iso-639
handling back in b8774b3c1a. this
corrects those mistakes, and in doing so brings this back into line
with all other use of the iso-639 lookup functions.
the mistakes:
1. the english/native comments were added the wrong way around.
2. the 2T fallback lookup was made unreachable.
after searching with the 2B code, we either have a match, or the
'unknown' record (which uses '?' characters). since every single entry
in the table has a non-empty 2T code (ignoring the irrelevant end
marker), and since the 'unknown' item also has a non-empty 2T code
("???"), the fallback path to search with 2T would never be triggered.
3. the avoidance of storing language code on failed lookup was broken.
the `*code` condition would always be true, since matching records
always have a 2T code, and for no match "???" is always returned from
the 'unknown' record. this means that for failed matches, "???" would
be unintentionally written into the entry.
4. the len==3 condition on iso-639-2 lookup was lost.
the previous code conditionally only performed an iso-639-2 lookup if
the string length is 3, just like all other cases of such lookups
throughout the codebase. there was no specific reason for this to have
been removed here. (this is going to get restored anyway momentarily
when the code gets de-duplicated by a new function).
5. an incorrect comment was given to the newly introduced function.
the new `GetIso639_2LangCode()` helper function it introduced always
returns len==3 strings, never len==0.
740d1347f0