Support multilingual sites with language undefined !?

Author of this module comments

simple_favs 2.0.10 was designed to support either unilingual non multlingual sites that have no language prefix
OR
Multilingual sites that have a two letter language prefix. This assumes that when using multilingual that each node gets a language assigned (not language undefined). only unilingual sites are able to use language undefined. If your nodes in a multilingual build have language undefined then they should be assigned to the language default of the site which assuming is not undefined. Howto fix this without patching simple_favs.

A way forward:

I'll consider patches that do not break functionality for existing builds.

NO PATCH NEEDED BY FIXING YOUR CONTENT AND CONFIGURATION:

To fix your language undefined nodes, write a schema update using a hook_update / mymodule_update_10001() , this function call goes into mymodule.install , in this schema update you'll need to set the language to your sites default language instead of language undefined. Then in your node bundle settings set the default language code to the sites default language.

Original reported issue:

I have a site that has content in two languages, English (en) and Irish (ga). The English version is set as the default so the language for those node is often set as undefined (und).

When viewing the favourited items in the "My Favourites" block, the URLs are incorrect and go to invalid routes on the site. This is because the url is created using the following code (js/favsBlock.js:64):

  const url = (langcode !== 'und') ? '/' + langcode + '/node/' + id : '/node/' + id;

The langcode is the language that the viewer requested and not that of the node, as far as I can tell. The value comes from drupalSettings.simple_favs.block.langcode.

This results in the generated URL as /en/node/123 and not the expected /node/123.

I see two possibilities to fix this. Either store the correct URL as is done with non-node URLs or return the URL in the call to /simple-favs/titles. I suspect the returning the URL in the JSON would be the preferred solution as that would account for changing the alias of the node.