- Microsoft dropped the ball... - 5 Updates
| Ian Collins <ian-news@hotmail.com>: Sep 19 12:46PM +1200 On 19/09/2020 06:06, Paavo Helde wrote: > least many times more expensive than the original project) these days, > even if printf or iostreams are not involved. Recent advent of > translation AI seems to make things worse, not better. You are lucky there! Our users are machine operators and technicians, so all the UIs have to be translated for each market - and the are a lot of them... Translation is an expensive and time consuming process which has delayed our product releases on more than one occasion. My team is lucky, all our UIs are handled by our Android and Web teams. -- Ian. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 19 11:18AM On Sat, 2020-09-19, Ian Collins wrote: > You are lucky there! Our users are machine operators and technicians, > so all the UIs have to be translated for each market - and the are a lot > of them... My end users have always fallen in the (broad) "technician" category, and I have never heard anyone even suggest the /possibility/ of localization. > Translation is an expensive and time consuming process which has delayed > our product releases on more than one occasion. My team is lucky, all > our UIs are handled by our Android and Web teams. There's that difference again (someone brought it up earlier): I've never been involved in anything with a GUI. Plenty of UI, but no GUI. Maybe localization isn't important to the customers, but their UX experts insist on it out of habit? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Juha Nieminen <nospam@thanks.invalid>: Sep 19 07:35PM > Well, I find it ironic that you bring up efficiency in the context of > iostreams, which are for sure the most inefficient way to output > something from a C++ program. How old is the information on which that claim is based? I myself compared the speed of std::fwrite() vs. std::ostream::write() and noticed a quite clear difference in favor of the former... something like 15 years ago. In order to update my experience I recently tried to repeat the experiment, but the results were extremely inconclusive because I was unable to get consistent results. The times I got were all over the place, from run to run of the exact same binary. (This could be due to a myriad of reasons, perhaps related to the hardware, the operating system, or the C runtime. But summa summarum, I couldn't get a definitive answer whether fwrite is still measurably faster than ostream::write.) |
| Ian Collins <ian-news@hotmail.com>: Sep 20 08:17AM +1200 On 19/09/2020 23:18, Jorgen Grahn wrote: > My end users have always fallen in the (broad) "technician" category, > and I have never heard anyone even suggest the /possibility/ of > localization. "Technician" in our context are those who calibrate the machines for customers and operators. This process can be quite complex and any misunderstandings can have bad consequences... > never been involved in anything with a GUI. Plenty of UI, but no GUI. > Maybe localization isn't important to the customers, but their UX experts > insist on it out of habit? Not for us; I can't imagine many international construction machine operators speaking good enough English to work with an English only UI. It is probably intuitive enough to learn, but localisation is essential in most markets - can you imagine selling an English only system in France? -- Ian. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 19 09:52PM On Sat, 2020-09-19, Ian Collins wrote: > operators speaking good enough English to work with an English only UI. > It is probably intuitive enough to learn, but localisation is essential > in most markets - can you imagine selling an English only system in France? I'm pretty sure we did it at my previous workplace, and we're doing it right now at my current one. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment