Thanks a lot for your comment.

1. The `kwargs` is sth I should remove here, it is confusing. It stems from this being taken out of a larger framework where the function can be called via kwargs or with the named parameters. Not ideal I know.

2. "I don't see why this should be solved as an NLP task in the first place. I mean the site the traffic of which you're analysing must have some internal mapping between the different language versions of the same page, which is probably stored in a database," => That's what I try to say with paragraphs like "For most of these examples, there usually is a way for your developers to provide monolingual values in your Data Layer. For instance, monolingual product data or generic URL paths / page names can often be derived from the localization logic of the Content Management System (CMS).

... While the feasibility of course varies from case to case, it ultimately always depends on how much your org wants to spend on developer resources for this problem..."

=> So in this case, yes, there should be a connection in the CMS (and there even is), but getting the development team to prioritize the implementation of this (=> to surface the "normalized" value in the Data Layer on the website) takes ages or will never get approved. With the NLPs, I have a "backdoor entrance" that does not waste anybody's tech resources and can be implemented in little time. As somebody doing web tracking, you constantly run into resource conflicts because most of the things you'd like to have in your tracking data need to be prioritized against the backlog of actual website features, and tracking is just not important enough to warrant too many resources usually. So you need to get creative... ;)

3. ("Finally"...) That is very interesting. I have to read up on BERT-like classifiers. Very grateful for such input.