How to design in every language at once(canvatechblog.com) |
How to design in every language at once(canvatechblog.com) |
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.
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.
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
> 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.
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
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.
The what:
greeting: "Hello"
or the where:
dashboard.header: "Hello"
edit: I guess you could do both
dashboard.header:
greeting: "Hello"For example:
title.welcome = "Welcome"
button.submit = "Submit"
But I think this is just a matter of taste. Use what works for you.
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.
It doesn't tell you anything about the time zone this particular user would want to see it in today, which depends on quite a few factors including where they are and what the timestamp relates to (booking, event, log of past events etc).
then you may be fine with that information loss. But is is one nevertheless.
But in applications where it matters, you make sure you know the source timezone where the data enters your system.
E.g. When comparing temperature charts from different places in different timezones, you may want to show them in a way that "noon local time" is on the same place of the X-axis in both cases.
Or more usual: I keep a log of what I do during a day. If I now move to another timezone and want to look at the log, I don't want the times shown in my current timezone. I want the timezone I was in back then.
If I schedule something for 1 pm 6 months from now, and a transition to/from DST is supposed to happen at some point during those 6 months, and then my country decides to not follow DST anymore or to follow DST year-round, once you update your timezone database and convert your UTC stored time to my timezone, it's going to either be 12 or 2 pm now. This is probably not what users want, unless they scheduled the event to happen a certain time interval after some other event that's not affected by timezones.
So a future event made before the time zone transition of a country? That's rare enough that I think a one-off transition plan would be fine.
Given the downsides of storing dates with time zones (comparison, confusion etc), it doesn't seem very attractive to me.
E.g. when during the day is traffic at its worst, when is temperature highest, etc.