
It’s probably never going to work in German - mikejb
https://increment.com/internationalization/its-probably-never-going-to-work-in-german/
======
crazygringo
> _Inter­nation­ali­zation is not a feature, it’s an architecture... It’s not
> something extra. It doesn’t take longer. It doesn’t require additional
> engineers._

That feels like the wrong way to convince people. Having worked with i18n and
l10n before, it absolutely is extra, takes longer, and on a very large team
can absolutely bump up to an additional engineer.

Producing dynamic strings becomes much more involved and requires more
testing. Handling RTL languages and layouts is another layer of things to
worry about and test. Giving the translators sufficient context for each
string is plenty of work, as is adjusting the design to fit strings that are
longer than you'd expected. Etc. etc.

That isn't to say don't do it. It's just yet another cost-benefit calculation
taking into account ease-of-use and market size. But pretending the cost isn't
there doesn't fool anyone -- it just makes them think you're bad at producing
realistic estimates and makes them less likely to trust you generally.

~~~
Vinnl
The problem with the "all engineers should internalise it into their
development process" mindset is that it's held by so many groups. Your
architecture should take into account internationalisation, security,
accessibility, etc.

At a certain point, no single engineer can keep up with it all, and produce
working and maintainable code - let alone all of them.

Unfortunately, I'm not sure what the solution is here.

~~~
TeMPOraL
I don't know what the ultimate solution is either, but it seems to me that
internalizing more and more things into the development process is one of, if
not _the_ main part of growing as a developer. It's not even about being a
specialist, just getting an intuition for design features that make it easier
to implement i18n/l10n/a11y/security features correctly.

And performance. For the love of all that is pretty, do remember to
internalize how to write non-wasteful code.

~~~
lumost
Part of growing as a developer is also knowing what you can do without, if you
have 3 months to bring an mvp in front of a single language customer - i18n is
the last thing on anyones mind, and delaying for even a day is a waste of
precious time.

This does not mean that time is the only thing that matters, if you know that
at month 6 you're going to launch in spanish - then you better look to avoid
major i18n pain points, and think ahead to ensure that between months 3 and 6
there is a viable project to internationalize the product.

~~~
derefr
If you’re in the US, maybe. If you’re building an MVP of a dating site for the
European market? i18n is feature #0.

~~~
goldfeld
Maybe an MVP for an European dating platform starts at the minimum of your
mother language, or say, the French market? What good is having every language
if your MVP marketing budget doesn't stretch enough to warm up the dating
scenes of several countries? Better hit big by divide and conquer than try to
hug the continent with your legs (to use a Portuguese expression.)

------
atemerev
My take on internationalization is that I want to see less of it.

I am Russian living in Switzerland, where people speak French, (Swiss) German,
Italian and Romansh. I often travel to Barcelona, where people speak Catalan
and Spanish. I don’t want any of these languages, I want all sites in English.

This is hard to achieve, as nearly everybody uses geolinked
internationalization. It is awful. Especially here in Switzerland — almost
every site tries to show me the German version by default (most of Swiss
cantons are German-speaking, but mine speaks French).

Please just use English. Or if you must, enable language selection in users
profile, do not try to detect it from geographic location.

~~~
zdragnar
Geographic location is incredibly ineffective anyway depending on your ISP and
other factors.

Rather than defaulting to English, why not default to whatever the browser's
OS is set to? At least for JS apps, there's navigator.languages, and there's
an Accept-Language header for both language and locale for standard server-
rendered plain ol' websites.

Geographic location really does seem like the worst possible option to use.

~~~
reaperducer
_Rather than defaulting to English, why not default to whatever the browser 's
OS is set to?_

As someone who develops multi-lingual web sites, I can tell you this doesn't
work.

It should work, but it doesn't. We test with actual users in their home
environments, and... people are messy.

\- The vast majority of our users accept the default language (English) when
setting up their computers, even if they don't speak English.

\- In households where the parents are immigrants, very often the children set
up the computer, so it's set to English, which is the child's preference, even
if the parents don't speak English.

\- Poor households often share a phone or a computer, and each person may not
speak or prefer the default language that was chosen by the person who set up
the computer.

In the idealized world that Silicon Valley imagines where 1 person uses 1
computer with 1 owner and speaks 1 language, it's fine. But in the real world,
it's just a mess.

~~~
pabs3
This sounds like something that web browser UX experts could help to fix.

~~~
rockdoe
They already did. Every major browser allows you to configure the language you
speak.

Of course it doesn't do much because sites do very stupid things like use
geolocation.

------
kasperni
> Likewise, you can’t just assume that people will always use a.m. and p.m.
> because some countries use 24-hour clocks.

As in 90-95 % of the countries in the world.....
[https://i.stack.imgur.com/43dwH.jpg](https://i.stack.imgur.com/43dwH.jpg)

~~~
TazeTSchnitzel
Including many English speakers. Please don't force me to use 12-hour time, it
hurts.

------
NicoJuicy
I integrate German, French, English and Dutch from the start.

They are all languages used in Belgium, English as a developer.

I've gotten it pretty productive. My database doesn't require extra tables and
it's fully customizable per client ( 1 extra table). Because my clients, also
want to label things differently according to their use-case. I control the
translations ( the default and custom ones). As long as it's logical. I agree.
I stop them when they don't use general words and try to create another use-
case for it. That would break the app functionality or changes expectations (
eg. Stupid example: Label Completed as invoiced because that's their end state
of a ticket). Then they need to adjust to the application workflow.

I have custom parsers for languages stored in the database ( description is a
multilingual column in the database for example).

According to what I know, I'm the only person I've met who goes that deep from
the start. And I have real advantages with it, as long as it's an application
that "my clients" own clients use. Language doesn't stop and culture, but it's
also niche and even "company behavior" related.

For integrating multiple languages...

If you live in America, it's an after thought.

If you live in Belgium, it's the first thing you run into.

If you're an SMB, you need to go deeper to differentiate.

To me, the title only makes sense to me when you're mother tongue is a
dominant language in the world ( reach for the stars).

What I haven't run into yet is right-to-left and Arabic, Chinese,.. ( non
Latin based languages) currently.

Using USD, pounds and EUR is handled within the frameworks I use. Dot Net uses
it extensively and yes, I use resx files ( which I don't like a lot, but I've
wrapped them and use them as default translations of a language, clients can
adjust them).

I don't need translators in the start. I can handle French, Dutch, English
myselve mostly. My German isn't very good though.. ( which sucks because of
the title here :p )

Ps. Yes, Changing translations is billable per hour.

------
stevoski
As per the article, internationalisation and localisation are harder than they
seem at first. But take the time to do them right and you can outsell your
competitors in certain lucrative markets.

My product has many competitors. In the US, the UK, and other English-speaking
regions it is a struggle to compete. But our team has experience with
languages and translation so that gives us the edge in markets outside the
Anglo-sphere.

------
emiliobumachar
Lots of the comments here are about preferring the version in English and
being frustrated by software in other languages, pushed based on geography or
some-such. These are valid experiences, I certainly learned from the comments
and share some of the frustration. But let's all keep in mind that this is an
English-language forum. Contributions, even more than readership, are from
people with fluent or nearly fluent English. So, biased sample and all that.
Generalize at your own risk.

------
anotheryou
As a german who used to do front-end, I'd have loved to delay those problems
in to the first i18n.

A "Cart" is a "Warenkorb" or an "Einkaufswagen" and both can't be shortened at
all. Oh and did you know the correct spelling for a price would be "1.999,00
€"? (with a space (which even germans find ugly), comma/dot swap and the
currency behind the number).

~~~
anoncake
"Korb"/"Wagen"?

~~~
currysausage
I'm not usually an advocate of icons, but in that case, an icon of a cart
would still be preferable. "Korb" looks like I can buy a basket and "Wagen"
alone usually means car. These meanings may not even make sense in the
specific context, but with Kruger's Fact of Life #1 in mind ("We don’t read
pages. We scan them."), the first connotation is actually what matters.

~~~
anoncake
> I'm not usually an advocate of icons, but in that case, an icon of a cart
> would still be preferable.

I think on most shopping sites, the cart button has both an icon and a label
anyway.

> These meanings may not even make sense in the specific context, but with
> Kruger's Fact of Life #1 in mind ("We don’t read pages. We scan them."), the
> first connotation is actually what matters.

The first connotation depends on the context though. If you add an icon to the
cart button and put it in the top right corner where people expect it, I
predict that people may find it harder to identify the correct meaning than if
you used "Einkaufswagen" or "Warenkorb", but only minimally.

~~~
zrobotics
But, in english, "Car" would be a valid (if useless) abbreviation of "Cart".
Seeing "Car" next to a cart icon would be just as confusing, which is why
abbreviations that are valid, common word are typically avoided. Sure, people
will likely figure it out, but it will look strange, since their first thought
on seeing "Wagen" will be "Why is there a car button? WTF is this for?" before
eventually deducing that it is the shopping cart.

To be fair, German is just a hard language to abbreviate, the compound words
really tend to work against this. I'm not a linguist, but I've always wondered
if the word length is one of the reasons English has borrowed so few German
words relative to the romance languages.

~~~
anoncake
But "Wagen" does not mean car. It's meaning is closer to "wheeled vehicle that
is not a bike". It's a hyponym to both "Auto"/car and "Einkaufswagen"/shopping
cart.

The Google Images results for "Wagen"[1] illustrate that "car" is by far not
the primary meaning.

[1] [https://i.imgur.com/iPQcD3B.png](https://i.imgur.com/iPQcD3B.png)

------
guitarbill
> The task force produced a book, basically. The book was on how Japanese text
> layout works.

Was this ever released publically/does anybody know the title or ISBN? Would
love to pick up a copy.

~~~
GuiA
Not certain, but perhaps:

[https://www.w3.org/2007/02/japanese-
layout/docs/aligned/japa...](https://www.w3.org/2007/02/japanese-
layout/docs/aligned/japanese-layout-requirements-en.html)

~~~
guitarbill
Thanks for digging that up! Finally a W3 document I enjoy reading; the
illustrations are superb.

------
TomK32
The quote from the article's title refers to copy and yes, with English being
a rather short-ish language, translated copy will fail to stay within design
constraints in pretty much all other languages.

On the other hand, except for Russians (and the dozen or so Canadians and
France which owns land in almost every timezone on the planet) pretty much
every country on the planet has just one timezone. So creating an app for the
US market brings that nasty problem.

------
mfritsche
Microsoft seems to increasingly use machine translation for their user
interfaces (really caught my eye in Azure DevOps). It mostly works... until it
doesn't, and the translation gives a word that's close, but not right in
context. It's annoying and makes me feel like they just didn't care enough.
Frankly, I'd prefer an English user interface over one that tells me "Yeah, we
checked the box, but couldn't care less!"

------
TazeTSchnitzel
This is one of the benefits of diversity on a team: you better understand the
diversity of your customers.

------
medecau
Offtopic but how do I subscribe to the paperback copy of Increment magazine?

At the time I got a free sample of their 5th issue - Programming Languages -
and asked about getting a copy of previous issues and subscribing to future
ones but never heard back from them.

------
Torwald
Amiga OS 3.0 did it right, anyone else here remembers?

~~~
bhaak
Unless you mean something else, locale support was already introduced in
AmigaOS 2.1.

And I'm not sure what you exactly mean by "did it right". i18n and
localization support is now in every OS and almost any UI framework available
today.

It was really great for its time but I wouldn't know of any feature it had
that isn't standard today.

~~~
Torwald
I never had a 2.1 machine, so I was mistaken there. Thanks for correcting
that.

To the point, I think the way the Amiga let a third party provide a
localization file was easier than in todays OS more end user friendly. It was
open and standardized across the OS. Not every app was cooking it's own
format.

------
Symbiote
> What makes a good i18n and l10n expert

Another pet peeve of mine: using lazy abbreviations like "i18n", "w/" or
"w/out".

These aren't even understood by many _native_ English speakers.

~~~
mattmanser
I would call them more a term of art in our industry than an abbreviation.

~~~
CharlesW
Fun fact: These are more specifically called "numeronyms".

[https://en.wikipedia.org/wiki/Numeronym](https://en.wikipedia.org/wiki/Numeronym)

