|
Oh my, don't get me started about Excel localization. It played a big part in my decision 20+ years ago to switch all my computers (any electronics actually) to US/English locale. Years later when I began programming seriously, I switched to a US-ANSI QWERTY layout — never looked back. The premise is simple and just works: - remove all friction (cognitive bloat) with foreign knowledge (blogs, docs, books, vids, courses, etc) because I don't have the additional step of translating, or rather guessing which snowflake word some engineer of my country thought was a good idea. - avoid waiting for translations, which may never come (been there, done that, burned by JP/US video games in the 1990's never making it to the EU, thank you very much... not). Currently this usually means a lag of anything between 3 days and 3 months to get features from US app stores to EU ones. Some features never make it past the English world (Amazon is very bad in this regard, the whole Alexa offer is much lesser outside the US in my experience). - I'll go one step further thus, and submit that even documentation, while written in local language usually, should at least retain English terms for fixed, known things — do not translate already formalized concepts like "reverse proxy", acronyms like DNS, cultural concepts like Agile or devops. It just makes it much, much harder for everyone to know what we're talking about, and to relate to the English world (makes your country, locale, a silo, which is bad-bad). Ideally, you'd write documentation fully in English, and optionally have a localized translation when it can't be avoided (regulation, compliance comes to mind). I love that there is a common language in our industry; which one is a distant concern (although I love English more than my mother tongue, so there's that for me). |