Updates to the NL translations#499
Conversation
…l changes, align with current latest version, add translation version
Add Dutch translator
|
@niekvangalen is attempting to deploy a commit to the Yuki Okushi's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
Deployment failed with the following error: |
|
@JohnTitor are you able to process this PR? The textual changes have been reviewed by a colleague of mine: https://github.com/LuudSlagter. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@JohnTitor |
There was a problem hiding this comment.
rebel 28,
"backwards compatible", in plaats van " backward compatibel".
| Het uitbrengen van een nieuwe packageversie kan al snel een nachtmerrie worden als systemen te maken hebben met een hoop afhankelijkheden. Als de afhankelijkheden te strikt gespecificeerd zijn, ontstaat het gevaar op "version lock": het is dan niet meer mogelijk om een package te upgraden zonder dat alle afhankelijke packages ook een versie verhoogd moeten worden. Als de afhankelijkheden te losjes zijn gespecificeerd, zul je onvermijdelijk worden gebeten door het fenomeen versievermenging: de verwachting dat er meer compatibiliteit is met toekomstige versies dan je redelijkerwijs mag verwachten. Je bevindt je in de hel van afhankelijkheden wanneer "version lock" en/of versievermenging zodanig in de weg zitten dat je project niet makkelijk en veilig kan worden voortgezet. | ||
|
|
||
| Als oplossing voor dit probleem stellen we een simpele set van regels en voorwaarden voor die beschrijven hoe versienummers toegewezen en verhoogd worden. Deze regels zijn gebaseerd op, maar niet noodzakelijk beperkt tot reeds bestaande en wijdverspreide gebruiken in zowel gesloten als opensource-software. Om dit systeem succesvol te laten zijn, is het als eerste nodig om je API publiek te declareren. Of deze nu bestaat uit documentatie of wordt afgedwongen door de code zelf maakt niet uit: het belangrijkste is dat de API duidelijk en exact is. Zodra je je publieke API geïdentificeerd hebt, worden wijzigingen gecommuniceerd met specifieke verhogingen in het versienummer. Gebruik een versieformaat van X.Y.Z (Major.Minor.Patch). Bugfixes zonder effect op de API verhogen de patchversie, toevoegingen en wijzigingen aan de API die compatibel zijn met de vorige versie verhogen de minorversie en wijzigingen aan de API die niet compatibel zijn met de vorige versie verhogen de majorversie. | ||
| Als oplossing voor dit probleem stellen we een simpele set van regels en voorwaarden voor die beschrijven hoe versienummers toegewezen en verhoogd worden. Deze regels zijn gebaseerd op, maar niet noodzakelijk beperkt tot, reeds bestaande en wijdverspreide gebruiken in zowel gesloten als opensource-software. Om dit systeem succesvol te laten zijn, is het als eerste nodig om je API publiek te declareren. Of deze nu bestaat uit documentatie of wordt afgedwongen door de code zelf maakt niet uit: het belangrijkste is dat de API duidelijk en exact is. Zodra je je publieke API geïdentificeerd hebt, worden wijzigingen gecommuniceerd met specifieke verhogingen in het versienummer. Gebruik een versieformaat van X.Y.Z (Major.Minor.Patch). Bugfixes zonder effect op de API verhogen de patchversie, toevoegingen en wijzigingen aan de API die backward compatibel zijn verhogen de minorversie en wijzigingen aan de API die niet backward compatibel zijn verhogen de majorversie. |
There was a problem hiding this comment.
"backwards compatible" in plaats van "backward compatibel"
There was a problem hiding this comment.
Thanks and agreed! Proposed change in #504

This PR refines the Dutch text linguistically and grammatically.
The wording has been reviewed by https://github.com/LuudSlagter to ensure correct and natural Dutch.