Glossary & style guidelines

[jochenboesmans]

🔧 WIP

Please add entries, suggest changes, whatever you see fit.

Guidelines

• Keep React- and programming-related terms in English.

• Capitalize all words in section titles. E.g. Inline If with Logical && Operator -> Inline If Met Logische && Operator

• Keep link formatting as close to the original as possible. E.g. keep bold ** formatting of CodePen links where applicable.

• Use links to Dutch articles where possible and clearly indicate that a linked article is English by using (Engels).

• Prefer using the je pronoun over u when addressing the reader of the article.

Glossary

Translate

English	Nederlands
encapsulated	omwikkeld / ingekapseld ❓
component(s)	component(en)
(rich) data	(rijke) gegevens/data ❓
declarative	declaratief
to declare	verklaren / benoemen ❓
technology stack	technologiestack
to render	renderen
method	methode
(function) accepts (arguments)	(functie) accepteert (argumenten)
(function) returns (arguments)	(functie) geeft terug / retourneert (argumenten) ❓
function	functie
argument(s)	argument(en)
to update	bijwerken
to invoke	aanroepen
markup	opmaak
list	lijst
list item	lijstelement
class	klasse
functional components	functionele componenten
attributes	attributen
uppercase letter(s)	hoofdletter(s)
lowercase letter(s)	kleine letter(s)
scope	bereik
expression(s)	expressie(s)
(im)pure (function)	(on)zuiver(e) (functie)
to embed	insluiten
curly braces	accolades
regular	regulier
to assign	toekennen
to represent	voorstellen
conditional	conditioneel
refactor	refactoren
performance	performance/prestaties ❓
to pass (arguments)	(argumenten) doorgeven
lifecycle (methods)	levenscyclus(methoden)
to (un)mount (a component)	(een component) (de)monteren / (un)mounten ❓
arrow function	pijlfunctie
composition	compositie
to bind	binden
controlled (components)	aangestuurde (componenten)

Keep as-is

English
state
templates
features
hooks
libraries
frameworks
input
output
inline
event handl(ing/er)
event delegation
props
DOM
tags
camel case
bottom-up
top-down
string
statements
loops
literals
bugs
keys
maps
body
constructor
resources
React
log
callback
mock
inheritance
UI
tree
node
children (node)
(grand)parents (node)
siblings (node)
syntax
views
read-only

[Keraito]

Awesome, great work on that list! 😍

Definitely agree with your first point. I've thought about it myself as well and tried to come up with translations for certain terms. And especially for the React specific ones (like props, state, render, etc.) I prefer to leave them untranslated. There's no point in 'forcing' Dutch translations on those as it will only create an exta barrier between the Dutch and English React communities.

Maybe for now, we should start the most common terms and decide rules for those. We can discuss and decide on how to translate less frequent ones on the fly. WDYT?

Will take a look at the rest of your list tomorrow!

[Keraito]

Based on your list, I think a lot of them are quite clear except for two categories: 1) terms that we should not translate to keep relevance to original docs and 2) the ones that are in the middle. For me those were:

Don't translate
state
stateful/stateless
input
output
props
DOM
Hooks
React

Term	Possible Translation
encapsulated	omwikkeld
declare	verklaren
function accepts arguments	functie accepteert argumenten
function returns	functie retourneert
update	bijwerken
invoke	aanroepen
list	lijst?
item (of a list)	element van een lijst?
curly braces	accolades (officiele term)
to assign	toekennen
to embed	insluiten
mount	monteren
arrow functions	pijlfunctie

In general, nice list though!

[ronderksen]

Nice list so far! I agree with Keraito's "don't translate" list. I have some suggestions for alternative translations:

term	possible translation	reasoning
To declare	benoemen	seems the simplest translation
function returns	functie geeft terug	easier to understand than "retourneren"
curly braces	accolades	official translation
syntax	syntax	difficult word anyway, Dutch translation doesn't make it easier
node	node	also for all derived terms
to (un)mount (a component)	een component (un)mounten	-

I think that translating jargon (like event, mount/unmount, etc.) doesn't make it easier to understand. Even though we can't assume that people who read the Dutch docs can also read the English docs, they will come across these terms in other writings.

[jochenboesmans]

Hey @ronderksen, thanks for your input! Personally, I prefer "geeft terug", "syntax" and "(un)mounten" as well. For the node stuff I'm fine with both Dutch and English terms. The only problem I see is with translating "to declare" to "benoemen" since there's some semantic difference between "benoemen" en "verklaren/declareren". Essentially it comes down to naming, but I would personally opt for either "verklaren" or "declareren". Anyway, I've merged your input into the table. Feel free to edit it if I made any mistakes.

[timlogemann]

Hi! I want to make a small contribution:
Personally I think views should not be translated either. Weergaven to me make it seem like we're talking about views for a YouTube video. 'Like I have 10 views on my video' instead of screens in a application.
And as it's also part of MVC, which I think should not be translated either, a should just be called what it is; a view.

[jochenboesmans]

@timlogemann Agreed. We'll keep "views" as-is unless someone objects.

[Kingdutch]

I haven't seen it discussed here yet so I may have missed the discussion elsewhere. I'd like to challenge the choice to keep Title Case in the Dutch translations. I think it's very much an American thing (Brits tend to lowercase some binding words 'with', 'and', 'or', etc.). When other examples of proper Dutch writing are examined (literature, newspapers, other websites) then Dutch titles often just follow the normal sentence capitalisation rules. In the given example I think Inline if met logische && operator is more readable for a Dutch person than Inline If Met Logische && Operator.

I'd also like to point you to the Dutch styleguide for translations of the Drupal framework that may give us some guidelines to copy: https://localize.drupal.org/node/2314 (it's easier to steal cleverly than invent poorly).

I've been doubting on my opinion for u vs je. At first I was leaning towards u which is used by the Drupal framework (I'm a Drupal developer by day). However, the target audience for those translations are users of a website where you do not know the relationship. I think the relationship with the audience of the React website is people that are interested in React and want to know more. Our community goals are to be inclusive and approachable. Therefor I would suggest that we standardize on je which is informal, setting the tone for learning without creating the formal distance that u may cause.

We should also ask one of the maintainers to pin this issue so that it's easy to find for people that want to get up and running with translating :)

[jochenboesmans]

@Kingdutch Thanks for your input.

Personally I think section titles should have at least some form of capitalization to make them stand out from the rest of the article. I don't think any languages really enforce a specific style and it's just a matter of preference. Some articles even go for all-caps section titles, for example. I personally prefer our current style, but let's leave the discussion open.

As for u vs. je, I think the consensus so far has been to use je where possible since it's more informal and reads just a little easier, as you said. I'll add it as a style guideline, but obviously it's still open for discussion.

I've also pinned the issue as you suggested.