[tdrdt]

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]

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

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]

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

[grey-area]

All that tells you is the timezone the user was in (or if you're unlucky the timezone the server was in) when the data was recorded. So it's not usually very valuable information.

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

[mro_name]

> So it's not usually very valuable information.

then you may be fine with that information loss. But is is one nevertheless.

[Scarblac]

Well, garbage in garbage out, of course.

But in applications where it matters, you make sure you know the source timezone where the data enters your system.

[grey-area]

Which applications does it matter for?

[5Qn8mNbc2FNCiVV]

You combine UTC with the Timezone of the user when it's rendered out and when you don't have that time (f.e. email to customer) you'll have to get a bit creative and calculate the timezone with the user data you have. If you only have an email and no other data, you include the used timezone so they can calculate their local time from that themselves.

[Scarblac]

To keep all information, you also need to store the timezone that the event originally was.

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.

[BiteCode_dev]

The debate that started this thread proved my point without needing any effort of my part :)