As a developer I never had much problems building systems in multiple locales. I think on the web this was solved over 15 years ago when UTF-8 became mainstream.
Over 10 years ago I built a webapp with over 20 locales without much trouble. This included ltr and rtl.<p>I think the biggest problem with any application is that designers always use text and images that fit in their design. But this is not the reality. I think developers can improve themselves if they understand this.
And also: developers can improve themselves when they don't build pixel perfect according to the design but know how to make it look good when texts don't fit the design.<p>If both the designers and developers know about building text-flexible applications they will have more value for the company they are working for.
A design should be seen more as a style guide. The end product must be better than the design.
Aside from the technical details, the commitment to this idea is staggering and admirable.<p>> Translations are done by human professionals, within two days for any language representing more than 0.03% of our active user base.<p>> New features roll out only when enough of the translation has been done that it will cover 99.8% of our user base.
I often forget how much utility I derive from knowing English in an online world (replace 'utility derived' with luck, privilege, blessings, etc to taste.) I am glad there are places making this effort. Localization is hard, and scaling is significantly harder. Hats off to Canva.
I've done a lot of i18n work in the past.<p>I found the hardest bit was managing the translation files, at least in Java. Java has a scheme where the you create files with key/value pairs of text id to translation. Instead of putting in text in your element "This is a button", you put in the text id "THIS_IS_BUTTON", and java's i18n would look for a properties file with a suffix of the current local and then pull the value for "THIS_IS_BUTTON".<p>It was enormously cumbersome for large apps
The "What did we do" section sounds like a product all by itself.<p>But seriously, I found this really interesting. Beyond any feel-goodness around supporting non-English speakers, I'd love to know if Canva has an idea of how much revenue they've generated from what sounds like a pretty big investment.<p>I would guess that in many of the 103 languages Canva supports they're the only game in town. That sounds like a good long-term strategy to me.
It's crazy that there isn't more support to simplify and standardize localization workflows in operating systems, SDKs, tools and file formats. IME a localization workflow today doesn't look much different than in the 90's, it's still mostly built around your own custom tools (or in some cases, framework-specific tools like the ones provided by Qt). Thinking about it, a high quality, human(!) translation service (no machine learning bullshit) for apps would actually be a feature where Apple or Google could justify their 30% fee.
Interesting article. How do people usually name their keys in their i18n data files? For example, do you name based on the 'what' or the 'where'?<p>The what:<p>greeting: "Hello"<p>or the where:<p>dashboard.header: "Hello"<p>edit:
I guess you could do both<p>dashboard.header:<p><pre><code> greeting: "Hello"</code></pre>
I wondered in college (in the 80's!) why all computer languages were in English. Fast forward 40 years, and somebody is doing something about it. Kudos!