fixed extract languages

[dkubatin]

Hi, @joshuatz!

Thank you for such a useful extension, it's just super!

Unfortunately, when retrieving the questionnaire, I noticed that the language proficiency was not retrieved correctly. Instead of language proficiency, the language of the questionnaire was extracted. My PR will fix it! :)

[joshuatz]

@dkubatin Hi! Thanks for contributing. Just wanted to give you a heads up that this is on my radar, but I'm a bit busy this week, so it might be a bit before I'm able to get to reviewing this and/or merging your changes.

[joshuatz]

Finally had a chance to look at this. Two things:

1. I'd be OK (I guess) with moving the language extraction from the generic profile summary object to the more precise nested language objects, but only if there was a benefit. For example, you don't have this in your PR, but the objects you are pointing to actually contain proficiency / fluency info, whereas the profileInfoObj.defaultLocale object (which I'm currently using) absolutely does not. There is a little bit more to it than that though, since I would need to also convert LI's enum values (e.g. "NATIVE_OR_BILINGUAL") into the appropriate string. I could work on this, and push commits onto this, or a new PR.

   • Also, as a side note, this section cannot be removed - see comment above.

2. The bigger issue here though, is that I'm not sure I agree with your updates to the shape of the schema and resulting output. It looks like this is what you are proposing the Language entries are supposed to look like:

interface Language {
    name?: string;
}

... but what makes you say that? Admittedly, the state of the Schema is very confusing (see my comment on #33), but neither v0.0.16 (aka stable), nor v0.1.3 (aka latest), and not even the earliest version (featured on the website looks like that.... They all look like how I currently have it:

interface Language {
    language?: string;
    fluency?: string;
}

Is there a tool you are using or something that is requesting the language object in that format? Or is there a new version of the schema I'm unaware of? I always welcome contributions, but I would hate to have this extension start producing output that is incompatible with other systems because it deviates from the accepted standard (even if that standard has multiple conflicting versions out there 🙃).

[joshuatz]

@dkubatin I'm closing this for inactivity / unresolved questions. If you object, please see my questions above - that discussion needs to be resolved before exploring merging this PR.

Regardless, thank you for your contribution.