? Those of you around for the announcement of Magento 1 may recall one… of the most significant features, of allll… ?
Serving catalog and marketing content for multiple locales from one cohesive application instance is a Big Deal®. Those of you who are new (or at least newer) to the world of digital commerce may not be aware, but, ten to fifteen years ago, ecommerce (as it was called back then) tended to focus on one locale, whereas the standard for businesseses today is increasingly cross-border and multi-locale. Localizing content for multiple locales was a marquee feature when it was announced for Magento in 2007. The platform’s ability to handle more than one locale set it apart from the field back then, and it remains a major strength for us among competing platforms even to this day – despite the ever-increasing pressure for digital commerce apps to facilitate cross-border, multi-locale commerce. This state of affairs begs the question: why aren’t more platforms better at localization?
I believe there are two reasons why people choose Magento for multi-locale requirements. The first reason is intentional and obvious: Magento is built to serve multiple scopes out of the box, and serving multiple UI translations and design changes for local markets is core DNA for us. The second reason is less obvious, but (paradoxically) more important: Magento’s architecture is built for customization.
At their most simplistic, requirements for a multi-locale site involve translation of content, catalog data, and configuration. Magento handles this scope of requirements with ease. However, cross-border commerce often requires multiple changes in the functional scope, things beyond mere language differences. For example: additional or different data required for an entity, changes to checkout flow, and differences in order processing and updates.
While we’d love to discover and develop the Full Scope of Functional Differences for the Entire World®, it’s impossible for any application – even Magento – to natively handle all permutations of commercial interaction. That said, Magento is present in more than 180 countries and in essentially every industry vertical. We clearly offer a solution which is being adapted to the varied requirements of these markets. Magento does it better than anyone, but we do it on the strength, expertise, and ability of developers and agencies the world over.
This reality prescribes a different kind of product approach than a typical software organization. Having recognized our adaptability to so many markets, I began talking this year about functional localization as a meta feature for our platform. Functional localization is analogous to language localization: just as users of the platform (whether consumer or admin) from a given locale expect to encounter their language when they interact with a site, they also expect the UX to be familiar. For example, consumers from China expect to use their mobile number or WeChat as an identifier and communication endpoint, rather than email (as is the case throughout Europe and North America). In Japan it’s standard to duplicate address and customer fields in order to provide phonetic spelling to complement Kanji attribute values. Developers familiar with Magento’s customer schema will immediately recognize the challenge these present to out-of-box schema, given assumptions that certain fields are unique identifiers for a customer (as well as a transactional update endpoint), or that a standard set of details are sufficient for order management.
The cool thing about Magento though is that, despite these challenges, there are innumerable sites already adapted to these different market expectations. The even cooler thing is that this is true in markets the world over. What keeps me up at night though is that in each market there are a number of extensions or vendors solving the same problems in slightly different ways, though they all achieve the same outcome. As a developer this makes me twitch because I loathe the idea of repeated work. As a software product representative I get cold sweats because we end up with multiple paths between input and output, all of which we have to think about as we move our application forward. Ideally we should be productizing these market-specific solutions, by which I meant that for each market we should have a publicly-exposed set of requirements as well as extensions which solve these requirements. Ideally, these requirements and solutions are sourced from our excellent, amazing open source community, much in the same way that we are resolving issues and adding features via Community Engineering. (I should be clear that there is a difference between productizing and commercializing.)
All that said, I’d like to invite you, dear reader, to pay attention for some work in this area in Q1 of 2018. We want to facilitate collaboration of our developer community to disclose or develop market-specific requirements and solutions. As I work to get this facility online, you can email your ideas to me at ben@magento.com. I look forward to your feedback & suggestions!