A reasonable best practice for multilanguage sites is to utilize a language variable (preferably in a data layer) and provide all the reporting in a single language (ideally localized to your report consumers). You would want to avoid having pages named differently to align with the language. Since you're also using a CMS, partnering with your developers is key in getting the data exposed consistently.
There are a few ways to do this, but let me cover the top 2 . (using the contact us example from another post above):
1.) Scenario: Developer is unable to expose metadata in a data layer
- Assuming you have your pages structured with the language at the top level, you can use URL patterns to extract the language:
ie:
English: https://my.site.com/en/contact-us.html
Spanish: https://my.site.com/es/contact-us.html
French: https://my.site.com/fr/contact-us.html
You could use a data element in DTM/Launch to capture this with a small JS snippet:
document.location.pathname.split('/')[1]
The above would first return the pathname which = "/en/contact-us.html"
Next, you're asking JS to split that value using "/" as a delimiter, returning an array (0="", 1="en", 2="contact-us.html").
Last, you're asking to return the value at position 1 of the array since all arrays start at 0.
2.) Scenario: Developer can expose a data layer
This option is the easiest one and involves exposing the language code in the data layer:
myDataLayer: {
page: {
name: "contact-us",
language: "fr"
}
}
Scenario 2 is by far the easiest for you as a marketer/implementor since the data layer can scale comfortably and provides more reliability than string manipulation or site scraping.
By putting this value in a prop/eVar, you can slice your pages by language or as mentioned above, create a VRS based on the language.
Hope that Helps
