Inheriting a language

When your platform is no longer suited to internationalise.

I’ve seen it happen a couple of times. And for good reasons of course! An organisation establishes its digital presence and focusses on a specific target audience, hence a specific language. Once the organisation proves to be successful, the logical step is to expand beyond the borders of a country.

This comes with its obvious challenges. The financial, logistical, marketing and content aspects of the endeavour are quite evident. And since the internet (nearly) has no borders, the step to adjust our online presence to accommodate these new customers seems trivial, right? We have a working digital solution, how hard can it be!

Requirements

In order to understand where the most pressing challenges lie at this point, let’s have a quick look at the demands a new market brings.

Venturing into a new country can bring

• a different assortment
• different financial rules
• all content in different languages
• possibly multiple languages per country
• different lawmaking
• different URL structure
• different information pages
• different localisation rules like date notation
• different ways to do promotions and attract attention

this list can go on and on, but the prime takeaway here is that you cannot maintain an N=1 approach anymore. Almost everything you deemed certain and static, becomes fluid under the pressure of serving multiple countries / cultures / languages. And one way or another, there will be technical implications that reach deep into the way you’ve always done things.

Friction

In order to know what the next logical step is to make, you’ll have to have a vision for where you want to be in the foreseeable future.

Since N!=1 when it comes to language and content, the strain of maintaining these by a dev-team will put a toll on your release cycle.

• developers will have to intesify communication with your internationalisation (I18N) and localisation (L10N) providers / teams
• I18N and L10N will have to be sequenced in front of the release of the feature, therefore slowing everything down
• bug fixes won’t strictly be about functionality but also about content changes

When you detect that these are happening in your organisation, it might be time to sharpen the responsibilities a bit.

The responsibility of tech

Typically, it is the responsibility of Tech, to enable business to pursue their goals. Technology should be an enabler, and not a blocker. It never should act or be perceived as such.

The responsibility of business

Besides holding the wallet and determining where to invest in, business should also provide the content and be able to adjust it at any given moment within the boundaries of the built framework, to maximise profit and stay true to strategy and corporate identity.

Technical implications

Relaying the responsibility of publishing content back to the business comes with am myriad of technical implications. But there are a couple that I’d like to highlight here.

(multiline) strings

When it in example comes the text on a button, it is important to have a translation engine that allows the translator to understand the context of the string that he or she is editing. Usually this becomes the identifier.

e.g. ‘button_checkout_step1_continue’ receives payload

• EN: “Next”
• NL: “Volgende”
• etc.

Doing so, allows you

• to query your translations and understand which are missing per language.
• easily add new translations
• differentiate based on context and action

It might be tempting to identify the string by its current content. However, this deprives business from freedom whenever they want (or need) to differentiate between different contexts in different languages.

Content

The majority of cultural differences are solved in content and doesn’t have to be engineered by developers. To reduce (and therefore strengthen) a solution to an enabling platform, it makes sense to start working with a headless CMS.

This way you give back the power of content editing to business, while you gain the space to create platform wide abilities like

• A/B testing, for features as well as the release of content
• Market segmentation
• Logging and metric collection

and many more cool features you now have the time for because you don’t have to bother with content anymore!

Hey techie! But what about the BUCA

That’s a hard one. It’s easy to see why there’s a BUsiness CAse in the long run, but it’s hard to put it on the agenda. So why is that?

Usually, agenda’s are managed (rightfully) by determining a WSJF. For those unfamiliar, the Weighted Shortest Job First. And in order to build this stuff, cost isn’t immediately repaid, and development will take a while. So chances are, you’re never getting it prioritised and therefore it will never happen.

About that Weight

• Make sure that strategy is factored in properly.
• Make sure NPS is factored in properly
• Set the value of the change in proposition off, to the value of entering a new country with a completely new product

About being Short

• invest in the system
• transition static to dynamic, until >50% is transitioned to dynamic
• only then create a roadmap to proactively migrate

Since this way of moving towards a good I18N and L10N system has everything to do with facilitating development, rather than delivering features, weigh it against other efforts that impact teams horizontally (like these), rather than vertically (like feature request).