What Internationalization Has In Common with Extensibility and Open APIs

国际化与可扩展性和开放API有什么共同点?

2020-06-27 02:40 Lingua Greca

本文共945个字,阅读需10分钟

阅读模式 切换至中文

“Isn’t internationalization premature optimization?” This is an objection that I’ve seen repeatedly, and one that I’d like to challenge. Premature optimization is building for use cases that aren’t requirements yet. Global reach is a general requirement. The choice of geographies hasn’t been made yet at the time you’re building your product. But if you don’t make it possible for users around the world to pull your company toward them, you’ll be forcing your company to bulldoze into those markets later on. You want to enable the gravitational pull of the market toward your product, not force an unnatural push. Localizability is a Type of Extensibility The purpose of extensibility is to build modular, maintainable software that can be customized by others. Knowing that local customization is a potential market enabler for you, why wouldn’t you build it in from the start? Internationalization, which is the process of making your software easy to localize, gives you the ultimate field of dreams effect. If you build it, they will come. But what if those users who want your product come from other markets, but they simply can’t get in because you’ve locked the doors? All too often, teams unintentionally tie bricks to their product’s feet by hard-coding things that prevent global adoption from happening later on. Internationalization is the skeleton key that can unlock the doors and enable your expansion into local markets whenever your company, or your global users, decide the time is right. All you need to do is make slight modifications to how you build your product from the beginning (see “27 Web Application Localization Best Practices.”) It might take some time to learn how to make them a standard and automated part of your development process, but once you do, you’ll be making your software internationally extensible. This is a pretty powerful concept! Imagine if you could make your software available quickly and easily to the world. What if you could give the power to the users to bring your product into their own local market? What if the software were written in such a way that people could drop in their own currency or date format, flip the interface around from right to left instead of left to right, and it were so easy to localize that local markets were empowered to pull you in? It would be one of the major market dynamic shifts of our times. Developers build extensibility into their software in order to be good citizens for future needs that they and others may have. They want to make it easy to make changes in the future, and extensibility supports that goal. Internationalization is no different. It’s all about making it easy to extend software into new markets someday. But engineers often think that localization is only about content, not about code. They see localization as something that can wait until later on. They often view it as just a marketing exercise, the act of bringing the software to market in a new country and language. The average engineer simply doesn’t know that the software they are building has to support localization from the most basic and fundamental layer of all — within the very lines of code they write. In reality, the engineers and UX researchers who build the product are the ones who have the most power to help the product reach its full global potential. Only they, and the work they do today, can prevent tomorrow’s blockers to local markets from being embedded in the software. Why Internationalization Basically Means Open APIs Developers have seen incredible success and adoption of their technology when they build clean, modular, and open APIs. Look no further than the well-known success stories of API-first company Stripe and the vibrant ecosystem of Slack. An easily localizable product can create the same ecosystem effect as those companies achieved. It enables others to create new offerings for different locales, so that people can hook into your software more easily and offer the same technology for different user groups in new geographies. Companies like Zapier have built a phenomenal offering by exposing business value from one service and enabling it to pass into another domain just by connecting different technologies together. Wouldn’t it be amazing if we could “bolt on” Japanese, French, German, and so on in a similar way? What if a software product didn’t have to be localized with so much hassle, but simply “locale-enabled” as easily as you can install an integration? We often think of APIs in terms of data, but not in terms of international user experiences. Yet the principle is the same — making it easier to connect two things together. All you need to do is prioritize making things easy to localize, and you’ll enable those other markets to connect with your product in a more seamless way. The market forces should pull your software in their direction. No more bulldozing your way into new markets to try to convince them to buy your software. Those markets should pull you in, simply because you’ve made it exceedingly simple and easy for them to do so. The reason I’d ask developers to reconsider internationalization and to view it like you view extensibility and open APIs is because the goals are ultimately the same. Truly great development teams want to enable others to do unexpected things with their software someday, so that it can achieve expanded reach. Because you want to enable your software to be a toolbox. Not a black box. Tweet WhatsApp Email Print
“国际化难道不是过早优化吗?”这是我反复看到的一个针对国际化的异议,我对此观点持质疑态度。过早优化是为还非必需品的用例构建的。全球可及是普遍要求。您构建产品的时候,还没有选择地理位置。但是,如果您现在不能让自己的公司吸引全世界的用户,那么以后就需要采取强制措施迫使公司进入这些市场。您想让市场自然地倾向自己的产品,而不是凭借不自然的推动力。 本地化是一种可扩展性 可扩展性的目的是构建模块化、可维护、可供他人定制的软件。既然知道本地定制对您来说是一个潜在的市场推动力量,那为什么不从一开始就进行本地化呢?国际化是一个让软件易于本地化的过程,能实现您梦想的终极效果。一旦您进行本地化,就能取得这些效果。 如果那些想要您的产品的用户来自其他市场,但是他们无法获得产品,仅仅因为您的产品不对这些市场开放,那该怎么办?很多时候团队无意中给产品戴上镣铐,硬编码阻碍了产品的全球普及。国际化是一把钥匙,只要您的公司或您的全球用户认为时机合适,它就能打开大门,让您得以进军当地市场。 您只需要从一开始就稍微修改一下产品的构建方式(请参阅“27个Web应用程序本地化最佳实践”)。可能需要一些时间来学习如何应用这些实践,使其符合您的开发过程的标准,一旦做到了,您的软件就具备了全球可拓展性。这是一个相当强大的概念! 想象一下您的软件能够迅速向全世界开放的场景。如果您能赋予用户权力,让其将您的软件带入本地市场;如果软件的编写方式能让用户可以使用本土的货币或日期格式,能从右到左而不是从左到右浏览界面,能非常容易进行本地化处理从而为当地市场所接受,那会怎么样?这将是我们这个时代的主要市场动态变化之一。 开发人员将可扩展性构建到他们的软件中,以便满足未来自身以及其他人员的需求,成为优秀的编程人员。他们希望在本来能更容易修改软件,而可扩展性是实现这一目标的支持手段。同理,国际化也是如此。这一切都是为了将来某一天能更容易地将软件扩展到新的市场。 但是工程师往往认为本地化与内容相关,而与代码无关。他们并不把本地化当成是亟待解决的事情,且通常认为本地化只是一种营销活动——将软件推向一个新的国家和语言市场。一般的工程师根本不知道他们正在构建的软件必须从最基础、最基本的层面,即在他们编写的代码行内,就支持本地化。 事实上,构建产品的工程师和用户体验研究人员是最有能力帮助产品实现全球化的人。只有他们,以及他们现在所做的工作,才能阻止未来进军本地市场的障碍物不被植入到软件中。 为什么国际化基本上意味着开放API 一旦开发人员构建了简洁、模块化、开放式的应用接口(API),他们的技术就已经被采用,获得了巨大成功。这一点体现在这两家公司的成功经历上——以API著称的Stripe公司和生态系统充满活力的Slack公司。一个易于本地化的产品可以创造出与这些公司所取得的相同的生态系统效应。它使其他人能够为不同的地区创建新的产品,便于人们使用您的软件,并为不同用户群提供相同的技术。 有些公司的商业价值体现在某一项服务,比如Zapier,通过将不同的技术连接在一起,使这项服务进入另一个领域,从而制造出卓越的产品。如果我们能如法炮制,把这一套应用在日语、法语、德语等中,结果岂不是很惊人?如果一个软件产品不需进行如此繁琐的本地化,而只需“启用区域设置”,像安装集成一样容易,那会怎么样呢?虽然我们经常从数据的角度,而非国际用户体验的角度来看待API,但是原理是一样的——让两件事更容易联系在一起。 您只需要优先考虑提高本地化操作简易性的问题,让其他市场与您的产品以一种更无缝的方式连接。市场的力量有助于您的软件的拓展,不再需要凭借外力开拓新市场,说服人们购买您的软件。 这些市场会接纳您,因为您的加入无须它们大费周折。 我要求开发人员重新考虑国际化,并像看待可扩展性和开放API那样看待国际化,是因为它们的目标最终是相同的。真正优秀的开发团队希望有一天能让其他人用他们的软件做一些意想不到的事情,这样软件就能实现更广泛的应用。 因为您希望自己的软件能成为工具箱,而不是黑匣子。 推文 WhatsApp 电子邮件 打印

以上中文文本为机器翻译,存在不同程度偏差和错误,请理解并参考英文原文阅读。

阅读原文