11–20 of 65 posts
This is why my company decided to go with a logging/messaging mechanism that stores messages by ID with parameters. We can get a log file from customers in France who see the error message in French, but we can read their log file in English because it's in a neutral format. This isn't a panacea, as it means that there's a bit more work involved to integrate with tools like Splunk, and we obviously don't log to anyth…
Actually you should switch to software that keeps localization in configuration space instead of code, allowing you to switch languages on a per-user, per-program or per-session. Having user-targeted messages hard coded is a bug.
Sterownik ekranu przestał działać, ale odzyskał sprawność.
This is a hard problem, at the same time; the translated log files[1] from work look something like this:
2009-12-13 14:21 BACK-E-00234
It's unlikely that the message mentioned in the article was hard-coded to Polish; instead the author is arguing about users and the searchability of non-English error messages. To increase the searchability, you need to include key details (e.g., "BACK-E-00234") that make the message significantly uglier to read. One possible way around this is to make sure your error dialogs are selectable/copyable (maybe put a button to do this), but on copy silently insert the search key details.
[1] Our untranslated log files look more like:
...parameter tags here...That's a big problem to learn computer in foreign language (If you had context menu with items: Afgdfguw, Eetgreg, Uga, Boo, which would you choose?)
If problems occur then, anyway, regular users are not those who would try and would fix them.
For an advanced user, sure, use language you want. And if you choose your native language and if you can't find a solution to your trouble, try different keywords. Or reinstall nVidia driver in english version.
English speakers will have a hard time to understand this.
And the issue is primarily due to the large online population and knowledge base of English-speaking people. You can find enough info about any topic if such population exists, i.e. I found a lot info about linux in German language, probably due to popularity of the OS in Germany.
Actually you should switch to software that keeps localization in configuration space instead of code, allowing you to switch languages on a per-user, per-program or per-session. Having user-targeted messages hard coded is a bug.
Yes, it is. However, if you don't include search keys in the text presented to the user, it isn't going help when you get a dialog that says (FTA): Sterownik ekranu przestał działać, ale odzyskał sprawność. That's missing something at the beginning or end that allows a search engine to say "aha! this is looking for this error message, which in English is this ". This is a hard problem, at the same time; the translate…
Nice item for a future GUI wishlist.
I'd go as far as to say everyone should just move to English for everything, not just Operating Systems.
I speak two languages: English and Russian. Though it drives me crazy when I have to use software and especially cellphones in Russian - I can't understand anything there. I'd say, everyone needs to know English, but I wouldn't like if majority switched to English as their only language. In my opinion, other languages help us to learn history of their countries.
This is why my company decided to go with a logging/messaging mechanism that stores messages by ID with parameters. We can get a log file from customers in France who see the error message in French, but we can read their log file in English because it's in a neutral format. This isn't a panacea, as it means that there's a bit more work involved to integrate with tools like Splunk, and we obviously don't log to anyth…
We have some older components that do spit out error codes. (like COMS, error -84413994005!) Sometimes the codes aren't specific at all and I have to install a debug version to get the information I need, or rely on a graybeard programmer to help me out.
These days programs are far too complex to rely on a limited set of error codes.
Actually you should switch to software that keeps localization in configuration space instead of code, allowing you to switch languages on a per-user, per-program or per-session. Having user-targeted messages hard coded is a bug.
Needless to say, the controls for overriding anti-aliasing or fog-table or z-buffer settings, translated to my native language, was completely incomprehensible. I still don't understand why they bothered.