Temporary languages available differ between Android and desktop

[cckozie]

Android build 149, desktop build 81.
After updating the list of target languages on both platforms.
Android languages starting with "qaa":

Desktop languages starting with "qaa":

[ChrisJarka]

That might be a 'good' thing. Since qaa languages are the temporary codes that the creator of the new language information for the database are told to use until the 'actual' code is assigned.
@vleong2332 could confirm
(But why KL is then the first language listed after the qaa languages? That's a puzzle)

[da1nerd]

@ChrisJarka it's becase KL has the characters qaa within it's name.

[da1nerd]

There appears to be more issues that just with the temp target languages. However, focusing just on those for the moment I notice the following:

android:

lotunube - qaa-x-1bb3c6 (not in api)
bambara - qaa-x-38ffdc (in api but not properly formatted)

desktop:

san chi - qaa-x-1bd91c (not in api)

Manually indexed from the command line

"qaa-x-1560c6" - "Loubala"
"qaa-x-731b78" - "kampetlet"
"qaa-x-b8828c" - "Lawng Tu"
"qaa-x-cf4e7c" - "sangwan"
"qaa-x-dc43f3" - "Langwau"

[PhotoNomad0]

Looking at language "mr" on ts-android. It looks like it has been upgraded to checking level 3, but calling library.index.findTranslations() it is reported as level 1. Maybe update is not updating checking levels?

[PhotoNomad0]

If I delete the database and run update, then mr shows up in the list. So I suspect an issue that updates do not change the checking level.

[vleong2332]

@neutrinog have those been changed? http://td.unfoldingword.org/api/templanguages/assignment/

[da1nerd]

@vleong2332 I don't use that url I use this one instead http://td.unfoldingword.org/api/templanguages/assignment/changed/ since I only care if they have been assigned to a proper language.

[da1nerd]

Updated the android door43 client library to fix a few bugs. It matches the api very closely with one exception.

qaa-x-1bb3c6 is mapped to lol-x-lotunube but both are shown in the list of target languages. Only lol-x-lotunube should be shown.

[da1nerd]

@vleong2332 are you still on td?

I found a few bugs.

[5:26]
There is a target language Bambara (am-x-mali) that seems to have an accompanying temp language (qaa-x-38ffdc) however these are not mapped together in the api. There is however another temp language Jula (qaa-x-2684f1) that is mapped to Bambara. I'm just guessing here but it seems that Bambara should be mapped to Bambara not Jula.

[5:27]
What this means from the user's perspective is we'll have two languages available for them to use. Bambara (am-x-mali) and Bambara (qaa-x-38ffdc).

[5:28]
So Jula (qaa-x-2684f1) is completely missing from the users's perspective.

[5:30]
A separate bug is:

[5:31]
The language Loubala (qaa-x-1560c6) exists in the langnames api however it should clearly exist in the templanguages api.

[da1nerd]

I fixed a number of bugs in the node door43 client and it seems to be working as expected now (except for some issues on the api). The android module is still giving some trouble and will need some more work.

Android is showing a lot of languages that are not mapped correctly. Of note: Lotunube: qaa-x-1bb3c6 android is not showing this as matched.

[da1nerd]

Note to self:
It is clear we should be clearing stale data from the index if possible. We can do so without danger of losing data for the following:

• langnames
• questionnnaires
• assigned temp langnames

this needs to be done in both the node and android libraries.

[da1nerd]

Android and desktop libraries have been updated to clear stale data when running updates.

NOTE: we do not clear the temp target languages, therefore stale data may occur if the languages are not correctly managed (assigned) on the server side.

[da1nerd]

I've opened up two issues regarding the api bugs mentioned above.

unfoldingWord-dev/translationDatabaseWeb#643
and
unfoldingWord-dev/translationDatabaseWeb#644