Yeah, you can also use VS to code, though I never tried this. I think you can also write your own VS code and then access it from within Godot too. Again, never tried it myself. A quick Google search threw this up: [Getting Godot 3 working with C# & Visual Studio Code on Windows 10! | IdiotCoder.com](http://idiotcoder.com/godot3-csharp-visual-studio-code-windows10/)

Quote:

If you’ve never started up visual studio code just start it up and keep it open. Then with godot create a new scene and save it. Now create a new Panel and save it. Create a sub Label node and rename it to “my_label” and edit the text to say anything really. Press the play button to make sure godot runs and shows the text. Update: forgot one important note, make sure in editor settings under Mono -> Builds that you select MS Build (System) instead on windows. This worked wonders for me, thanks to this guy for the suggestion. Go to editor -> editor settings and select Visual Studio Code from the External Editior drop down option. Now add a script to the label and select C# from the language drop down and hit create. This should open my_label.cs in visual studio code without any issue. Inside the _Ready() methods body add the following: GD.Print("Hi");

There's Godot Engine, but it uses its own scripting language. The language is pretty quick to learn, although it has its idiosyncrasies. The architecture might also be a bit confusing at first the way it's set up with scenes and nodes etc. if this is your first foray into the field. The documentation is also at best so-so. I was lucky enough to have someone help me with the basics and answer my noob questions, so I got off to a quick start. Thought I might as well throw it out there as an alternative.

I have worked as a translator for ~15 years. I have translated UIs and have managed the translation of the UI in a large-scale product. I can tell you with 100% certainty that you do not want to use Google to translate your UI if you want to appear even remotely professional. That is because - as has been pointed out - Google has no idea of context. Many words have a lot of different meanings. Just take the example of the word "right", which, depending on context, will have a lot of different translations. There is no way that Google can decide on the right translation. It will simply choose one of the many options that are possible. So it's very possible that your users will see things like "Access Rights" as "Access legal entitlements" or something similar. As you can tell, that will only make your users question your sanity. When we sent out the UI to be translated, we were always extremely wary of translation agencies who would send back 10s of thousands of strings without having a single question about context. That's when we knew they were poor and we switched to a new translation agency. It's a surprising truth that a lot of translation work is outsourced to Google translate, and then reviewed by a human (or in some cases not). These translations are by and large useless. In some cases we had to refuse payment because of lack of performance by the agency. We were perfectly capable of running the strings through Google ourselves; that's not what we were paying for. This is a big issue because a UI will includes lots of single words (buttons, headers, menu options) that require translation, which means there is absolutely no context to go on if you look at just that one word. That's why you expect the translators to send you a long list of questions about those strings where multiple translations are possible depending on context. It's also why I documented many of the strings to clear up these questions a priori wherever possible. You can test this yourself. Take a sentence, any sentence, and enter it into Google translate. Then translate it into a language of your choice and back into English. A lot of the time, it sort of makes sense, sometimes it makes perfect sense, sometimes it's gobbledygook. Some language pairs work better than others, some sentences work better than others. Now enter the same sentence, and translate it from English to Spanish, then to French, then to Arabic, then to Chinese, and then back to English. You are guaranteed to get complete gibberish. Next, do the same

First of I'd answer your actual question (do devs have a UI responsibility) with a resounding "yes". As to why US companies insist on forcing the rest of the world to use an illogical date format that practically no other country uses? I think it's the same underlying reason why we get poor UI's in general: wrong mindset. As a dev, your job is to write software for **your users**, not for yourself/your ego. This is something a lot of developers seem to forget/aren't aware of. That means putting yourself in your users' shoes and designing software that meets your users' functional requirements while also being a joy to use. Poor UI design generally is the result of only the first part of this equation being deemed important: meeting the functional requirements. The ease of use is an afterthought, and you can guarantee the dev never actually used the UI in a real life situation (they might, if you're lucky test a few boundary cases). A prime example of this was the drop-down list in Outlook years ago for choosing the year of birth for a contact. Not only was this a drop-down list with 100 entries or so (one per year), the default value was the current year at the top of the list. Now if they'd tried entering the data of a real person or two, they would immediately have realised that none of their users will have an address book full of babies born this year, and that selecting something like "1967" from a massively long list is a UI fail. But if all you test is "date in the past, today, date in the future", you won't ever see the massive design flaw. MS fixed this in a subsequent update. And this mindset - whereby people find it difficult to empathise and put themselves in other people's shoes - is also the reason for these weird date formats nobody (apart from Americans) wants. As a programmer, you must know that there are different date formats (you should at least know ISO and your local format if it's not ISO). So it can't be ignorance, it can only be an unwillingness to put yourself in your users' shoes. Because if you did, you'd immediately understand that no one wants to use an unfamiliar and confusing date format. If your mindset is "we don't care about anyone else", your software suffers as a result. And it won't only be the date format that suffers.

That's not what I said at all.

BryanFazekas wrote:

Ok. Get involved. If it bothers you that much, contribute to the project and fix it.

This. It's how open source works. If you care enough about something, add it/fix it yourself. Otherwise you don't care enough. That might sound harsh, but it's also the harsh reality that people working in their free time only have so many resources, and have their own personal interests. If you - someone who needs the fix - don't care enough to at least try and fix it, why should someone else, who has no need of that feature and has 100 other bugs to take care of? It's not because of attitude, but because the day only has 24 hours and you are one of a large number of users - all of whom think their personal needs are more important than some other random feature they will never use, and all of whom are lobbying the poor devs :) So the devs have to make decisions and determine priorities. In an ideal world, every good idea would make it into the software, and every issue would be fixed. In the real world, a more pragmatic approach is needed that weighs up the benefits and effort to determine which things make it onto the To-Do list. You say yourself, you are a programmer. Surely, you have also had to make decisions of this nature: do I spend 2 weeks trying to track down and fix a weird esoteric bug that only 2 people have experienced, or do I add a much-requested feature that will improve the experience for the vast majority of users? You can't always do both. That's not to say I don't sympathise with you! It's a crying shame that there is generally very little awareness about how to make software more accessible. I like to assume it's not a case of people not caring, but of simply not being aware that what many of us take for granted can be a real problem for other people. For example, a green/red traffic light status indicator might not be such a good choice for the colour blind. But if you're not colour blind, it's quite a challenge to realise this could be an issue without someone pointing it out to you. So at the end of the day, I think this is less about you and a lack of understanding of your needs, and more about cost-benefit. It's simply not worth fixing the esoteric bug when there are far more users who have other pressing needs.

Totally agree with this - you will need to get others on board if you want to solve this problem. That means winning them over to your side, rather than creating the impression that it is you vs them. In addition to adopting a more encouraging tone, I would suggest that you tackle the issue not from the point of view of "what is wrong" but "how can we improve". Telling someone that the work they performed is crap will always feel personal, whether it is true or not. Creating the feeling that we are working together for a common good will be much more productive and also resolves the you vs them feeling: make it us vs the problems instead. At the end of the day, the easiest way to sell things to organisations, is by selling the benefit. If someone has had a frustrating time fighting through poorly documented spaghetti code, they really shouldn't need much convincing that there has to be a better way. The same goes for management; they might not know what refactoring is or what the benefits are. They might think that spending time on code that already exists is a waste of resources. It is your task to open their eyes to the efficiency and cost savings that proper engineering brings with it. If you can convince people of the benefits of changing their work habits and make it in their own interest to do so, you will probably have much more success. After all, nobody likes doing work that is a PITA or unnecessary.

You learn something new every day.

You make a convincing argument there. Does tinfoil protect against cats?

SpecFlow, the popular open source Cucumber port for .NET, has been updated to version 2. The SpecFlow+ Runner extension has also been updated to support SpecFlow 2. The latest version of the test execution suite introduces support for the NUnit 3.0 and xUnit 2.0 test runners, including parallel test execution. Other new features include support for Gherkin 3, the ability to determine the hook execution order, extensible table conversions and comparisons, and many other improvements and fixes. More details on the changes in V2 can be found on the SpecFlow website and in the changelog on GitHub. SpecFlow+ Runner has also been updated to version 1.3 for compatibility with SpecFlow 2. SpecFlow+ Runner is a paid extension for SpecFlow that integrates directly with Visual Studio’s Test Explorer and extends SpecFlow with additional features such as HTML reports, execution statistics and smart test execution. Existing SpecFlow+ users can upgrade to the latest version free of charge until the end of February, even if their upgrade period has expired. SpecFlow is open source licensed under BSD and developed by an active community from around the world. Providing Gherkin support for .NET, SpecFlow is the test execution platform of choice for agile development with Visual Studio.