Back Auf Deutsch lesen

Privacy policy

1. Who is responsible

The controller within the meaning of the GDPR is the operator of this installation; the name and address are in the imprint. No data protection officer has been appointed, and § 38 BDSG does not require one here.

2. What this application does

This application manages the translation files of an app. Two kinds of people use it: a handful of administrators with an account and a password, and volunteers who arrive through a shared link and proof-read finished translations.

Whether volunteers have to say anything about themselves is decided by the individual project. Normally they do not: you read along with no name and no address. But a project can be set so that a confirmed email address is a condition of taking part at all — meant as a defence against automated abuse. Which of the two settings applies is obvious immediately: either the texts appear straight away, or you are asked for an address first. Section 4 says what each of those means.

It is more honest to say this straight away: “we collect no personal data” would be untrue. Even with no name and no address, every browser that reads along is given a random identifier — and an online identifier is personal data under Art. 4(1) GDPR and recital 30. What that identifier is, and why it exists, is the next section.

3. Cookies

This application sets three cookies and no others. There are no third-party cookies, no advertising cookies and no analytics cookies — which is why there is no banner asking for consent to any.

3.1 The review cookie (crv_…)

As soon as somebody starts checking texts, their browser is given a cookie named crv_ followed by the project's number. It contains a random string of 64 characters and nothing else: no name, no address, no IP address. It expires after one year, is HttpOnly (JavaScript cannot reach it) and SameSite=Lax, so that it is still there when the link was opened from a chat message or an email.

That string is the identifier everything a person contributes hangs on: which texts they have already judged, which wordings they proposed, what they voted for. It links one person's visits together across a year. That is exactly what makes it personal data.

Our position on § 25 TDDDG (the German implementation of the ePrivacy rules): we consider this cookie strictly necessary under § 25(2) no. 2 TDDDG and therefore do not ask for consent beforehand. Without the identifier the service somebody is using would not exist: the application could not tell anyone what they had already checked, would hand them the same texts over and over, and a suggestion could neither be withdrawn nor attributed. That is a position, not legal advice; whoever runs this installation should know it and be willing to hold it. The legal basis for the processing that follows is Art. 6(1)(f) GDPR — the legitimate interest in not asking unpaid people to do the same work twice.

Anyone who deletes the cookie is, to this application, a new and unknown person. The judgements they already made stay in the database but are no longer linked to any browser.

3.2 The light/dark cookie (i18n_theme)

Whoever uses the switch in the page header to choose light, dark or “follow my device” is given a cookie containing exactly one of those three words. It also expires after a year, and it is only set when somebody actually uses the switch.

Honestly here too: the “strictly necessary” argument is weaker for this one than for the review cookie. The application works completely without the setting — it would just not look the way the person asked for. We consider storing a display preference that the person set themselves, deliberately, to be covered by § 25(2) no. 2 TDDDG; anyone who does not share that reading will find no other way to change it in the application than not using the switch.

3.3 The session cookie (administration only)

Only somebody who signs in with an email address and a password additionally receives PHP's session cookie. It keeps the sign-in for 24 hours, is HttpOnly and SameSite=Strict, and is gone on sign-out. Volunteers never get it.

4. What volunteers may give — and when they must

Two details are at stake, and whether they are voluntary depends on the project's setting (section 2). Normally both are optional, both are clearly marked as optional at the field itself, and both may be left empty without anything being withheld:

  • A display name. It becomes publicly visible only if the project runs a thank-you page and the person explicitly agreed to it.
  • An email address. It exists so that progress can be found again on another device and — if ticked — for two notifications per language (“there are new texts”, “this language has shipped”). There is no password: signing in works through a link in an email that is valid for 30 minutes and can be used once. Every email also carries a permanent unsubscribe link.

In this normal case the legal basis is Art. 6(1)(a) GDPR (consent), and it can be withdrawn at any time: the address can be changed on your own profile page, and the unsubscribe link stops the emails immediately.

4.1 When a project requires an account

With the stricter setting active, the email address is no longer a voluntary detail but the condition for taking part: without it, no texts are handed out. The address must also be confirmed — only the click on the link that was sent unlocks anything. The display name stays voluntary even then.

Our position on the legal basis: pointing at consent under Art. 6(1)(a) GDPR would be dishonest here — consent has to be freely given, and a detail without which you cannot continue is not that. So we rest this case on Art. 6(1)(f) GDPR: the legitimate interest in protecting a participation form that stands open on the internet against automated abuse, and in being able to attribute contributions to somebody reachable. Anyone who does not want that does not take part in such a project — the application knows no route without an address in this case, and that is what this setting costs.

5. What is stored while proof-reading

  • One judgement per text and language — “reads fine”, or a vote for somebody else's suggestion — with the time and with checksums of the two texts that were on screen at that moment. Those checksums are the reason a text comes round again when it has changed since.
  • Proposed wordings. Other volunteers see the text of a suggestion but never who wrote it. The administration sees both.
  • The question “where is this text used, and what for?” with an optional note of at most 500 characters. It goes to the administration only.
  • A coarse “last seen” timestamp, updated at most once an hour. It is not an access log.

Skipped texts are not stored. Clicking past a text leaves nothing behind in the database.

6. IP addresses: two brakes, and nothing else

This application stores an IP address in exactly two places, both of them brakes against automated abuse, and neither of them a log of who read what.

Failed sign-ins to the administration. On a failed sign-in, the address that was typed, the IP address and the time are recorded. That is the brake against guessing passwords (five failures per address in 15 minutes). Volunteers never trigger it — they sign in nowhere. As soon as a sign-in with the same address succeeds, those entries are deleted; whatever is left is deleted automatically after 24 hours.

Requests that can send an email. Leaving an address and asking for a sign-in link are the two things a stranger could use to put mail in somebody else's inbox, so both are counted per IP address (five per hour). The counter holds the IP address and a timestamp and nothing else — not the address that was typed, not what was asked for, not which page it came from. Entries fall out of the window after an hour and are deleted automatically within 24 hours.

The legal basis for both is Art. 6(1)(f) GDPR, the legitimate interest in keeping one's own installation and other people's mailboxes usable.

7. Server logs

The web server this application runs on will as a rule keep logs of its own, with IP address, time, requested address and browser identification. Those logs are not part of this application — they happen one layer below it and are neither visible nor switchable from inside it.

This installation runs at ALL-INKL.COM — Neue Medien Münnich, owner René Münnich, Hauptstraße 68, 02742 Friedersdorf, Germany. The servers stand in Germany; the data does not leave the European Union. There is a data processing agreement under Art. 28 GDPR with the provider. By their own account they delete those logs after seven days at the latest.

8. Email

This application sends email only if the operator has switched it on, and only to people who left an address or who work in the administration. While sending, the configured mail provider sees the recipient, the subject and the content.

Sending goes through the mail server of the same provider that hosts this application — ALL-INKL.COM — Neue Medien Münnich (address in section 7). So no additional company is involved, and the same data processing agreement under Art. 28 GDPR covers both.

9. Machine translation (DeepL)

This application translates texts by machine, and it uses the service provider DeepL SE, Cologne to do so.

Two kinds of text are transmitted to DeepL in the process: the app's texts that are to be translated — and, since the administration can read a wording back, a volunteer's own proposed wording, so that it can be shown in the source language. Only the text is transmitted; who wrote it does not go with it.

Those texts are the app's own — labels, hints, sentences from its interface. They hold nothing about the person reading or proposing them: no name, no address, no identifier from the cookie.

It still belongs here rather than being left out: these texts are transmitted to DeepL and afterwards sit with a company neither the volunteers nor the reader of this notice has any say over. Anyone proposing a wording of their own should expect that exact sentence to go there. This server sends nothing by itself: every transmission is started by the administration.

10. Screenshots

The administration can attach a screenshot to a text so that volunteers can see where it appears in the app. Those images sit on the server under a random file name and are publicly retrievable — there is no other way, because the people who are meant to see them are not signed in. Anyone who knows the file name can open the image.

So: screenshots must not show real names, addresses, messages or any other data about third parties. That is a duty of care on the administration, and one the application cannot enforce.

11. The “Contact” control in the footer

Whatever is written there goes as an email to the administration of this installation and is not stored anywhere — the email is the only copy that will ever exist. Giving a reply address is optional; without one, no answer is possible.

12. What this application does not do

The following is not a statement of intent but a property of the program that can be checked against its source:

  • No analytics, no tracking, no statistics services. There is no analytics tool, no counting pixel and no profiling.
  • No requests to anybody else's server when a page is opened. No CDN, no web fonts (the device's own fonts are used), no embedded maps or videos. The JavaScript library these pages use is stored on this server; the stylesheet is built before delivery and shipped with the application. While viewing this page the browser loads from this server only. The only outgoing connections are sending mail and DeepL, and both happen because the administration asked for them, never when a volunteer opens a page.
  • No inclusion in search engines. Every response from this server carries X-Robots-Tag: noindex.

13. How long things stay

  • Judgements, suggestions and context questions: as long as the project runs, or until the administration deletes them.
  • Display name and email address: until they are changed or removed on your own profile page — or deleted on request (section 14).
  • Sign-in links: valid for 30 minutes; the spent entry is deleted after 7 days.
  • The review cookie and the light/dark cookie: one year.
  • The administration's session cookie: 24 hours.
  • Failed sign-ins and the IP counters: 24 hours — see section 6.
  • The log of sent emails (kind, time, recipient group — not the content): 90 days.

The periods in this list are not a statement of intent: a cleanup runs on this application's own schedule and actually deletes them.

14. Your rights

Access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20) and objection (Art. 21) — and withdrawal of a consent, at any time and with effect for the future. The contact details are in the imprint.

One thing first, so that nobody writes in vain: somebody who read along anonymously is, to us, only the random string in the cookie. Without it we cannot bring a person and their contributions together — which is the situation Art. 11(2) GDPR describes. Anyone who left an email address can be found; anyone who did not should send the request from the same browser.

There is also a right to lodge a complaint with a data protection supervisory authority. The competent one is the Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen, Postfach 20 04 44, 40102 Düsseldorf, Germany — ldi.nrw.de. You may also turn to the supervisory authority where you live.

15. Changes

When what this application does changes, this text changes with it. Last updated: 1 August 2026.