There are some valid reasons to use software in English as a German speaker. Main among those is probably translations.
If you can speak English, you might be better of using the software in English, as having to deal with the English language can often be less of hassle, than having to deal with inconsistent, weird, or outright wrong translations.
Even high quality translations might run into issues, where the same thing is translated once as "A" and then as "B" in another context. Or run into issues where there is an English technical term being used, that has no prefect equivalent in German (i.e. a translation does exist, but is not a well-known, clearly defined technical term). More often than not though, translations are anything but high quality. Even in expensive products from big international companies.
This is definitely a problem that can occur, but for the one I was thinking of originally when writing the comment, we had pretty much all the resources available: the company sold internationally, so already had plenty of access to high-quality translators, and the application we were building was in-house, so we could go and ask the teams themselves if the translations made sense. More importantly, the need was also clearly there - many of the users of the application were seasonal workers, often older and less well-educated, in countries where neither English nor German were particularly relevant languages. Giving buttons labels in our users' languages meant they could figure out what they needed to do much more quickly, rather than having to memorise button colours and positions.
You're right that sometimes translation for technical terms is difficult, but the case I experienced far more often was Germans creating their own English words, or guessing at phrases they thought ought to exist because their English was not as good at they believed.
I agree that high quality translations are hard, and particularly difficult to retrofit into an existing application. But unless you have a very specialised audience, they're usually worth it!
Compiler errors or low level error messages in general are a good example. Translating them reduces the ability of someone who doesn't share your language to help you.
I'm actually of the opinion, that blue-green colors like teal or turquoise are both green and blue at the same time. Basically a mixture.
Having to pick just exclusively one - blue OR green - for such colors just feels, wrong and arbitrary?
You could also make a website that shows various shades of purple - and ask people is it blue or red? Well, both! Purple is a mixture of both blue and red. Why treat teal differently than purple?
Raph Koster is also currently working on a new game, that aims to take this ideas of social experience and player-driven virtual society and push it beyond what they were able to do with UO. (Also with less PK-ing, griefing, etc. - things he regretted about UO, but many people today consider synonymous with sandbox)
Interestingly enough, this new game is NOT going to have any shards or sharding at all - not even instancing - but just many (procedurally generated) planets, that are all part of the same shared universe and economy.
Thus, some of the very unique ambitions behind UO and SWG might actually become part of a new, more modern game:
weirdly enough, when asking for documentation/problem solving types of questions - chatGPT actually is a good alternative. you still have to double-check since you can't trust it... but you shouldn't trust random google results either, so that's not a big change.
it's kinda weird how the web has increasingly become optimized for bots - and filled with content created by bots... to the point where as a human you now need a bot to cut through all the bloated SEO bullshit and filter out what you actually want to know...
Regardless of whether you hire in-house developers or hire a software studio that does contract work - I believe the key to success is giving the developer unfettered access to an experienced subject-matter expert who really understands what is needed.
No offense meant - but by my personal experience, executives like yourself are a bad choice for this - some experienced longtime employee that's deeply involved in day-to-day operations in the trenches, would be preferable, I think. Ideally somebody who went through process changes before - like was already working there before your current software had been introduced.
Don't get a developer who wants to start programming right away - you want somebody who asks for time to first really learn and understand the processes the software needs to cover - and who actually questions all the underlying approaches your current software takes - but does not just rule those out out of hand.
Then get that senior employee to mentor them and teach them the job - not the existing software. I would even advise have the developer DO the work for a while - under the supervision of that senior employee.
If you can speak English, you might be better of using the software in English, as having to deal with the English language can often be less of hassle, than having to deal with inconsistent, weird, or outright wrong translations.
Even high quality translations might run into issues, where the same thing is translated once as "A" and then as "B" in another context. Or run into issues where there is an English technical term being used, that has no prefect equivalent in German (i.e. a translation does exist, but is not a well-known, clearly defined technical term). More often than not though, translations are anything but high quality. Even in expensive products from big international companies.
reply