It looks like the current language report is simply a 1-1 translation of system language codes sent by the user agent [en-us = "English (United States)"].
When we require a level of granularity such as understanding language codes, such as for engineering decisions, this obfuscates the data, meaning that we have to translate it back.
On the other hand, we rarely make business decisions based on granularity such as UK/Australian/Canadian/US English. When we are looking to generally understand how users of different languages behave, this falls short, because it's difficult to group parent languages together to understand aggregate metrics and trends.
My first thought would be to build a classification like this:
language code|language name|language parent
en-us|English (United States)|English
en-gb|English (United Kingdom)|English
However, we have no ability to deal with Adobe's languages report via processing rules or SAINT, and no desire to eat up another custom variable to process data already collected. Building, managing, and aggregate segments to collect the data post-processing is laborious on our admins and analysts. It would be far simpler if Adobe introduced the flexibility of looking at this data in the reporting tools, including language code and parent language. From a business user perspective, parent language would be the most meaningful.
