Avoid translation where possible, because every translation is additional effort and may introduce bugs.
The key contribution of "Domain Driven Design" to modern software engineering is the concept of a Ubiquitous Language, which is a single language used by all stake holders of a project. According to DDD, translation should not occur within a team (which includes domain experts, even if present only by proxy of a specification document), but only between teams (further reading: "Domain Driven Design" by Eric Evans, in particular the chapters about Ubiquitous Language and strategic design).
That is, if your business experts (or your specification document) speak Dutch, use their (Dutch) terminology when expressing business concerns in source code. Do not needlessly translate into English, because doing so creates an artificial impediment for communication between business experts and programmers, which takes time and can (through ambiguous or bad translation) cause bugs.
If, in contrast, your business experts can talk about their business in both English and Dutch, you are in the fortunate situation of being able to pick the project's ubiquitous language, and there are valid reasons for preferring English (such as "internationally understandable and more likely to be used by standards"), but doing so does not mean that coders should translate what the business people are talking about. Instead, the business people should switch languages.
Having a ubiquitous language is particularly important if requirements are complex and must be implemented precisely, if you're just doing CRUD the language you use internally matters less.
Personal anecdote: I was in a project where we exposed some business services as a SOAP endpoint. The business was entirely specified in German, and unlikely to be reused as is in english, because it was about legal matters specific to a particular jurisdiction. Nevertheless, some ivory tower architects mandated that the SOAP interface be English to promote future reuse. This translation occurred at hoc, and with little coordination among developers, yet alone a shared glossary, resulting in the same business term having several names in the web service contract, and some business terms having the same name in the web service contract. Oh, and of course some names where used on either side of the divide - but with different meanings!
If you choose to translate anyway, please standardize the translation in a glossary, add compliance with that glossary to your definition of done, and check it in your reviews. Don't be as careless as we have been.