Once you’ve created some Languages, set one as primary, and have some customers with locales set, it’s important to understand how the Advanced Billing application will apply those Languages to an invoice.
We will always try to use the closest match of a particular field to the customer’s locale. This means that translations from a matching Full-Locale field will be displayed if present, and then a language-only field will be displayed if present. Then we will use the Advanced Billing provided defaults for that language if present. Then the site’s primary language translation of a field. Finally, we would apply the Advanced Billing application default (English). Essentially, it’s possible for a given customer’s invoice to be pulling translations from multiple Languages based on a defined hierarchy.
Currently, Advanced Billing provides default values for the following languages: (English (en), and Spanish (es)). We are working to add more full base language translations.
Here’s how the hierarchy works:
1. Full Locale Match:
This is the highest priority of Custom Translations. If a customer’s locale matches exactly the Full Locale (e.g. es-MX) of a set of custom translations, we will display any overrides for this language. If any values are not present here we would then fall back to:
2. Language Only Match:
This is the second highest priority of Custom Translations. If a customer’s locale (either full locale or language-only) matches a set of custom translations for ONLY that language code (e.g. “es-MX” would match with base “es”), we would then display any over-rides for this language bypassing any over-rides that existed for the full locale match above. If any values are not present here we would then fall back to:
3. Advanced Billing Provided Language Translations:
As noted above, we currently provide FULL base translations for the referenced languages. This is the third highest priority AND the final layer IF the customer’s locale language matches an Advanced Billing-provided set of translations. We would display any base values here bypassing any overrides from (1) and (2) that are present.
4. Site Primary Translations:
If (3) is not present for the customer’s locale language, then the next level of priority would be the set of custom translations determined by the merchant as the Site Primary. We would display any over-rides within the Site Primary bypassing any over-rides set in (1) and (2). If any values are not present here we would finally fall back to.
5. Advanced Billing Application Default:
Any values not present in the above hierarchy would default to the application default of English base values.
Language Application Example
I have a site that offers a product in Central America. I create a “Spanish - Base” Language and create overrides for most of the fields on an invoice. At the same time, I have customers in many different countries: Mexico, Costa Rica, and Belize.
I set the locales on my customers appropriate to each one: “es-MX”, “es-CR”, and “es-BZ”.
For the most part, my existing “Spanish - Base” translations are fine for those customers, except for a few key fields such as “Billing Address” and “Shipping Address”.
I can then create Language Locales for “es-MX”, “ex-CR”, and “ex-BZ” and select “Customize Language” and create Country/Region overrides just for those few address fields that need to be different for each Country/Region.
When those customers view their invoices, they will see the invoice using their Language Locale-specific translations for the “Billing Address” and “Shipping Address” fields. But the “Spanish - Base” fields that have been set as primary are utilized everywhere else.
If that “Spanish - Base” primary does not have all of the fields with overrides, then those customers will see the Advanced Billing Provided Spanish translations and that’s it.
If, however, this entire example was for Italian with no Advanced Billing provided Italian base translations, then these customers would see the Site Primary translations for missing values and finally the Advanced Billing Default English translations for any missing fields.
We are working on providing more default language-specific translations and as they are available we will provide updates. For now, translations must be provided by users.