6 ms·

How to design in every language at once

85 points by fmihaila 5y ago

brigandish 5y ago
Aside from the technical details, the commitment to this idea is staggering and admirable. > Translations are done by human professionals, within two days for any language representing more than 0.03% of our active user base. > New features roll out only when enough of the translation has been done that it will cover 99.8% of our user base.
- cungminh 5y ago
  Thank you. Our goal is to empower everyone to design. And localization is one aspect that could help us achieve that.
fnord77 5y ago
I've done a lot of i18n work in the past. 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". It was enormously cumbersome for large apps
JoeAltmaier 5y ago
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!
vosper 5y ago
The "What did we do" section sounds like a product all by itself. 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. 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.
- cungminh 5y ago
  Hi, one of the authors here. Localisation has lots of positive impacts on us. I can't go much into details but majority of paid customers are from non English speaking countries.
rnoorda 5y ago
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.
flohofwoe 5y ago
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.
- cungminh 5y ago
  Hi, one of the authors here. ICU format from Unicode and Format.js libraries definitely simplify our localization workflow. However, the main challenge is to empower designers and engineers to create impacts without any i18n blockers and to allow translators to get meaningful context and therefore deliver accurate translation
deleted 5y ago
[deleted]
tdrdt 5y ago
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. 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. 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.
- BiteCode_dev 5y ago
  > As a developer I never had much problems building systems in multiple locales. That's really not the hard part The hard part is to follow all the legal and social conventions. Formats for dates and money, symbols and colors that you can or cannot use, making sure you get timezones right, serving a right to left design to the middle east, dealing with the various way to enter a phone number or a home address, translating efficiently db content or SPA pieces... Just translating from a *.po file, yes, it's easy.
  - tdrdt 5y ago
    I was not talking about translations only. Formats for dates and money are available in almost every programming language as library. You don't have to invent this yourself. The same for timezones, as long als all dates in your DB are UTC. And inputs for phone numbers and addresses fall in the category of 'Falsehood programmers believe about...'. If you store your data normalized all the programming language locale libraries make your life easy. /2c
    - mro_name 5y ago
      > as long als all dates in your DB are UTC. times don't have to be UTC but need the timezone info attached - be it implicit (all are UTC) or explicit, e.g. in text form rfc3339. Stripping the time-zone is information-loss and usually not desirable.
reidjs 5y ago
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'? The what: greeting: "Hello" or the where: dashboard.header: "Hello" edit: I guess you could do both dashboard.header: greeting: "Hello"
- tdrdt 5y ago
  Personally I like to add the context of the string, not at what place it is used. For example: title.welcome = "Welcome" button.submit = "Submit" In my experience this makes reusing of texts much easier and there will be less to translate. Because the same welcome title could be used in the dashboard header but also at other places. But I think this is just a matter of taste. Use what works for you.

85 points by fmihaila 5y ago

Aside from the technical details, the commitment to this idea is staggering and admirable. > Translations are done by human professionals, within two days for any language representing more than 0.03% of our active user base. > New features roll out only when enough of the translation has been done that it will cover 99.8% of our user base.

cungminh 5y ago
Thank you. Our goal is to empower everyone to design. And localization is one aspect that could help us achieve that.

fnord77 5y ago

I've done a lot of i18n work in the past. 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". It was enormously cumbersome for large apps

JoeAltmaier 5y ago

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!

vosper 5y ago

The "What did we do" section sounds like a product all by itself. 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. 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.

cungminh 5y ago
Hi, one of the authors here. Localisation has lots of positive impacts on us. I can't go much into details but majority of paid customers are from non English speaking countries.

rnoorda 5y ago

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.

flohofwoe 5y ago

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.

cungminh 5y ago
Hi, one of the authors here. ICU format from Unicode and Format.js libraries definitely simplify our localization workflow. However, the main challenge is to empower designers and engineers to create impacts without any i18n blockers and to allow translators to get meaningful context and therefore deliver accurate translation

deleted 5y ago

[deleted]

tdrdt 5y ago

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. 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. 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.

BiteCode_dev 5y ago
> As a developer I never had much problems building systems in multiple locales. That's really not the hard part The hard part is to follow all the legal and social conventions. Formats for dates and money, symbols and colors that you can or cannot use, making sure you get timezones right, serving a right to left design to the middle east, dealing with the various way to enter a phone number or a home address, translating efficiently db content or SPA pieces... Just translating from a *.po file, yes, it's easy.
- tdrdt 5y ago
  I was not talking about translations only. Formats for dates and money are available in almost every programming language as library. You don't have to invent this yourself. The same for timezones, as long als all dates in your DB are UTC. And inputs for phone numbers and addresses fall in the category of 'Falsehood programmers believe about...'. If you store your data normalized all the programming language locale libraries make your life easy. /2c
  - mro_name 5y ago
    > as long als all dates in your DB are UTC. times don't have to be UTC but need the timezone info attached - be it implicit (all are UTC) or explicit, e.g. in text form rfc3339. Stripping the time-zone is information-loss and usually not desirable.

reidjs 5y ago

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'? The what: greeting: "Hello" or the where: dashboard.header: "Hello" edit: I guess you could do both dashboard.header: greeting: "Hello"

tdrdt 5y ago
Personally I like to add the context of the string, not at what place it is used. For example: title.welcome = "Welcome" button.submit = "Submit" In my experience this makes reusing of texts much easier and there will be less to translate. Because the same welcome title could be used in the dashboard header but also at other places. But I think this is just a matter of taste. Use what works for you.