Update Dutch language file about robotframework HOT 3 CLOSED

I have posted a notification in the rf-nl and rf-be Slack channels announcing the update without a planned deprecation period for RF7.1.

from robotframework.

Dutch translations have now been updated. The old terms were simply replaced by new ones which makes the change backwards incompatible.

from robotframework.

I looked at making it possible to deprecate translations instead of just removing them. Based on my experiment that is certainly possible, but it is a bit more complicated than I anticipated. Apparently nobody in the Dutch speaking community raised strong backwards compatibility concerns, so I believe just changing the terms is fine as long as it is mentioned in RF 7.1 release notes.

If needed, we can look at deprecation again even before RF 7.1 is released. I'll briefly explain my experiment and what challenges there were:

1. I added a deprecated dictionary to the Language class with an idea that old terms would be keys and new terms would be values. This information would then be collected to the higher level Languages object similarly as other translation info. This API would be pretty convenient for translators and I would prefer to use that also if we implement deprecation support for real.
2. The first challenge in implementation was that deprecations would need to be checked in all places where translations are used. This means few different places in parsing (at least headers and settings are handled separately) and at least BDD-prefixes and Boolean strings during execution. Not overly complicated, but going through all translation usages is some work and all these usages also would need test.
3. During parsing we must add error information to the parsed tokens, not to print it to console or raise exceptions. This makes errors available for IDEs and other tools using the parsing model, but we then need to report the errors to users separately when the execution model is built as part of normal execution. Unfortunately this particular error reporting doesn't work too well at the moment and it would probably need to be enhanced to make all this work properly. The main problem is that the parsing model doesn't have a proper way to separate real errors (e.g. invalid setting) from warnings (e.g. deprecations). This limitation has caused as problems also earlier and fixing it would be good, but that obviously requires some additional design and coding work.

from robotframework.