Explore Internationalization Best Practices
After completing this unit, you’ll be able to:
- Describe the three international strategy approaches.
- Explain the importance of using real knowledge about each language when localizing.
- Explain the benefit of using non-localized templates.
- List three benefits of geographic POD proximity.
Salesforce B2C Commerce has been building multi-country, multi-language, and multi-currency sites for years. With more than 2,000 websites in 50 countries, internationalization is a definite strength. So what are some of the best practices that can help you plan and implement a strong international strategy?
Choosing your approach is a good start. Should you configure one site, groups of sites, or a site for each country?
You should also consider:
- Language and how text is translated
- Configuration and development best practices
- The APAC region
- Your deployment strategy and its impact on personnel
Phew! There’s a lot to consider. Let’s start with the strategy.
At the planning stage, you need to identify the best strategy from several approaches, each with advantages and disadvantages.
- One Site: Build one unique storefront to address all your targeted countries.
- Group Sites: Group some countries together, based on shared currencies, legal requirements, or language. Build several sites to address all targeted countries.
- One Site for Each Country: Build a site for each targeted country.
The best practice approach depends on the merchant’s context and constraints. Use this table to help determine the impact.
|Option 1: One International Site||Option 2: Group Sites||Option 3: One Site Per Country|
|Number of Sites||One||The number of countries (per currency)||The number of countries|
|Number of Catalogs||Two||The number of currency groups plus one||The number of countries plus one|
|Number of Price Books||One per currency||One per currency or locale||One per currency or locale|
|Complexity in Business Manager||Low||Medium||High|
Customize for localized experience
Customize per site
One team can manage all countries in the site
One team per site (country)
|Navigation||One navigation||Each group of sites has its own navigation||Each site has its own navigation|
||Max 3000 per inventory list per site||
|Content||One content library||One content library per site (or group)||Each site has a local library, or use a shared library across sites.|
||By group||A/B tests are site-specific. There’s no way to run a single test across multiple sites.|
You also need to consider personnel resources. Does your strategy have organizational consequences? Do you need to ramp up specific people and skills? Are the objectives realistic?
A person’s language is a big part of their identity. Shopping online needs to be as easy as having a great conversation. Just translating the words isn’t enough. When planning for localization, you need ensure the process uses real knowledge about each language to ensure a truly localized website experience for the shopper. Using common expressions, appropriate language, and proper spelling also protects SEO.
Speaking of SEO, here are some international considerations.
- Choose the domain type wisely. For SEO, specific geotargeting steps are required at launch for an international site to be recognized and displayed in country-specific search engines.
- Countries with a .co-Domain top-level-domain (TLD) want to use .com sites. Best practice is to keep the local TLDs and redirect them to subdomains that are primarily used for business. For example, redirect www.brand.de to http://de.brand.com and operate from there.
- For all branded material, such as package and printings, use the unified brand.com. A single .com-Domain helps you to achieve better SEO scores because all content is summed up in its weighting.
Configure and Develop
How you configure data in Business Manager and create templates can impact an international project’s success.
Configure Business Manager
In Business Manager, you can configure:
- Site and organization locales
- The organization default language
- Language stemmers for each index, ensuring the best performance for search and navigation
- Attributes and configuration parameters
It’s best practice to populate storefront data in the default locale for the site, and possibly the organization. This is because B2C Commerce uses built-in fallback logic to determine which content to display on the storefront.
This is the processing order.
- It displays the localized file, if available.
- If no localized file exists, it displays the site default locale.
- If no site default file exists, it displays the organization default locale.
For example, if a company is located in Toronto, Canada, its site default locale is set to default, and its site locales are en_CA, fr_CA, and default. Its organization default locale is set to en_CA. A shopper wants to see localized fr_CA content, but for some reason, it hasn’t been uploaded.
This is the fallback process.
- If there’s no fr_CA file, B2C Commerce displays a default file.
- If there’s no default file, B2C Commerce displays an en_CA file.
Templates contain the storefront display logic, including error messages and element text, such as button names. Creating a set of templates for each locale means that you have to edit each locale-specific version for every change. This isn’t the answer.
The best approach is to create one non-localized template set that references external localizable strings. The strings are located in separate resource files that can be sent to a translator for localization. With this approach, the storefront display logic remains non-language-specific, yet references language-specific resource files.
As a functional architect, you need to be aware of certain APAC functional requirements.
|Storefront Language||Simplified Chinese||Japanese|
|Storefront Currency||RMB||JPY (display 1,000円 or ¥ 1,000)|
|Encoding||UTF-8 for both front-office display and database|
|Product Pricing||Input by admin excluding taxes. The taxes must be added when displaying products (5%).|
||COD (Cash on delivery)|
|Delivery Time||Customers want to choose the time of delivery.|
||Mix of many|
|Maps||Use Baidu map|
The deployment strategy starts with:
- The point of delivery (POD): a collection of computing, networking, and storage services that combine to host a multi-tenant SaaS application.
- The realm hardware and software that B2C Commerce provides for the storefront.
For international implementations, this is no different, but there are some additional considerations that deal with geographic proximity between the shopper and the POD and shared resources.
Geographic proximity between shoppers and the POD can affect storefront performance (response time). To reach the APAC market, for example, B2C Commerce has PODs located in Asia.
With local hosting, site performance is faster for the checkout process. Scheduled maintenance is faster because there are no scheduled interruptions during peak shopping times. Job schedules are faster for product imports, as well as price and inventory updates, because they are done per local night times.
Shared Objects and Resources
Because objects can be shared across all sites within a realm, a merchant can streamline merchandising, development, QA, support, and maintenance for all sites. A merchandising team can work collaboratively on schedules, processes, and priorities.
The admin, development, or operations team can work collaboratively as well.
- Code, jobs, processes, and functionality must be scheduled, prioritized, and configured to address the needs of all the sites.
- Creating individual controls at the site level in these areas is nearly impossible within a realm, due to the inherent sharing that’s architected within the sites in a realm.
Selecting single versus multiple realms means considering efficiency versus control.
|Role||Single (Efficiency)||Multiple (Control)|
|Partner or development team||Single||Multiple|
|Code and release schedule||Common||Different|
|Merchandising||Shared (common view) across sites||Different between sites|
|Support and maintenance||Shared||Different|
|Project prioritization and resourcing||Common||Different|
|User credentials management||Shared||Different|
Let's Wrap It Up
We learned a lot about general architecture best practices, such as separating business functions from code and not using iFrames. We also learned about best practices for storefront design, mobile best practices, and now, internationalization. A best practice right now is that you earn a shiny new badge!