Cookie Policy

What this policy covers

This Cookie Policy explains the cookies and similar technologies we use on traduora.co and in Ever Traduora — the public website, the documentation, the signed-in application, and any desktop or mobile application we publish for it. The product-specific section below lists what is actually in use on each of those surfaces.

It sits alongside our Privacy Policy. The two documents answer different questions, and it is worth knowing which one you are reading:

• This policy is about your device. What we store on it, what we read back from it, why, and how you control that.
• The Privacy Policy is about the information itself. What we do with personal data once we hold it, the lawful basis for each purpose, who receives it, how long we keep it, and the rights you can exercise over it.

Where something described here involves personal data, the Privacy Policy governs that processing. Nothing in this policy narrows the rights that document gives you.

What this policy does not cover

Other people's sites and services. Our pages link to third-party sites, and our Service connects to third-party tools when you ask it to. Once you are on someone else's site, their cookie notice applies, not ours. We have no control over what they store on your device.

Your own workspace, your own site, your own people. Where you use the Service as a customer to run something of your own — a workspace for your organisation, or a site we provision for you — the pages you publish and the people you invite are yours. This policy is not your cookie notice to your own visitors or personnel, and our banner is not your consent mechanism. Providing those is your responsibility, on your own domain, under your own control.

A copy you run yourself. Where the software behind the Service is published as open source and you run your own deployment, this policy describes the service we operate — not yours. You choose what your deployment loads and what it stores on your users' devices, and only you can describe it to them.

Cookies and the other technologies that behave like them

A cookie is a small text file that a website asks your browser to keep and hands back to a server on later requests. It is the oldest way of doing this, and the best known — but it is only one of several, and the rules that matter here do not turn on which one is used.

The law we work to attaches to storing information on your device or reading information back from it, whatever the mechanism. So wherever this policy says "cookies", read it as covering all of the following.

The technologies

• Cookies — as above. Set by the site you are visiting, or by another provider whose code runs on the page.
• Local storage and session storage — key-value storage inside your browser. Larger than a cookie, not sent automatically with every request, and it can hold exactly the same kind of identifier.
• IndexedDB and the browser cache — structured storage and cached files. Ordinarily used to make pages load faster and to let parts of the Service work offline, but capable of holding an identifier too.
• Pixels, beacons and tags — a tiny image or a short script whose only job is to load. The act of loading it tells the provider that a page was opened, or an email read, along with your IP address and browser details. A pixel often stores nothing at all and still reports on you.
• Tracking parameters in links — identifiers added to a URL so that a click can be attributed to the campaign or message that produced it.
• SDK identifiers in desktop and mobile applications — an installed application has no cookie jar. It stores identifiers in its own application storage instead, and may use identifiers the operating system provides: an advertising identifier, an installation identifier, or a push notification token.
• Device and network characteristics — your IP address, screen size, language, time zone, fonts and browser version. Individually unremarkable; combined, they can form a fingerprint that recognises a device without storing anything on it.

First-party and third-party

First-party means we set it, on our own domain, and it goes to our servers.

Third-party means it belongs to another company whose code we have chosen to run on the page — an analytics provider, an embedded video player, a bot-protection service. Their technology reports to them, not to us, and they decide what it does. Note the awkward part plainly: a third-party resource embedded in our page discloses your IP address, your browser and the page you were on to that provider, even when it stores nothing on your device at all. Loading it is the disclosure.

Some third-party technologies are deliberately set up to look first-party — served from a subdomain of ours, or routed through our own servers. Where we do that, we say so in the table below rather than letting the appearance stand.

Session and persistent

Session items are discarded when you close the browser or the application. They are typically what keeps you signed in and moving through a single visit.

Persistent items survive until they expire or you delete them, which is what lets us recognise a returning visitor, remember your preferences, or remember that you refused something. Each entry in the table below states how long it lasts.

Why we use them

There are six reasons, and each one maps to one of the categories in the next section. We have written the category next to each so you can see immediately which ones you control.

• To sign you in and keep you signed in. Your session has to be attached to the right account, the right workspace and the right organisation as you move between pages, and it has to be protected against being replayed or forged by someone else. → strictly necessary
• To keep the Service secure. Telling a person apart from an abusive script, protecting forms against automated submission, enforcing rate limits, and detecting fraudulent sign-ups and payments. → strictly necessary
• To make the Service work at all. Routing your request to a healthy server, keeping you on the same one where a feature requires it, balancing load, and serving the right version of the application. → strictly necessary
• To remember what you decided about cookies. Your choice has to be stored somewhere, or we would have to ask you on every page. → strictly necessary
• To remember your preferences. Language, time zone, theme, layout, a panel you collapsed, a message you dismissed, and whether you want the support widget open. → functional
• To understand how the Service is used. Which pages and features people actually use, which paths fail, and where things are slow — so that we improve the right things rather than the ones we happen to notice. → analytics
• To measure our marketing. Whether a campaign reached anyone, which content leads to sign-ups, and which organisations show interest in the product. → marketing

Two things follow from that list, and we would rather state them than leave them implied.

Only the first four are needed for the Service to function. Everything in the last three groups is optional. If you refuse all of it, every feature you are entitled to still works, at the same price.

Where we can achieve a purpose without storing anything on your device, we do. That is the whole reason our own analytics is built the way it is — see the section on analytics without consent below.

The four categories we use

Every entry in the table below belongs to exactly one of these four categories. The banner and the preference centre use the same four names, so what you agree to and what this policy describes are the same thing.

1. Strictly necessary — no consent, because the Service cannot run without them

These are the ones we set because you asked for a service that cannot be delivered otherwise. They are not optional, they are not used for analytics or marketing, and there is no switch for them in the preference centre. If you block them at the browser level, parts of the Service will stop working.

• Session and authentication — signing you in, keeping you signed in, refreshing your session, and binding it to the correct account, workspace and organisation.
• Security — protection against cross-site request forgery, detection of abusive automated traffic, rate limiting, and fraud prevention on sign-up and payment.
• Load balancing and routing — sending your request to a healthy server and keeping you there where a feature needs it.
• Your consent choice — storing what you decided, so that we can honour it and stop asking.

Error and crash diagnostics are not in this category by default. Where we use a diagnostics tool that records more than a technical error — a reconstruction of what was on your screen, for example — it is listed under analytics and it waits for your consent.

reCAPTCHA is in this category, and here is our reasoning

We use Google reCAPTCHA — and on some surfaces an alternative provider, named in the table below — to stop automated abuse of forms such as sign-up, password reset and contact. We treat it as strictly necessary, which means it loads without asking you first.

The reason is that it protects the specific form you are trying to use. You cannot meaningfully ask for the form and refuse the protection on it: without it, those endpoints are abused within hours, which is a security failure that harms you as much as us.

What that means in practice, stated plainly:

• It collects device and behaviour signals from your browser — mouse and touch movement, timing, browser and device characteristics, and your IP address — and sends them to Google, which acts as its own controller for that data under its own privacy notice.
• We load it only on pages carrying a protected form. It is not present across the whole site.
• Where an equivalent provider is available on a surface, we prefer the one that collects less.

Not every data protection authority accepts that a bot-protection service belongs in the strictly necessary category. We think it does, for the reason above, and we would rather publish the reasoning and let you judge it than bury the tool in a list. If you would prefer not to submit a form protected this way, write to [email protected] and we will take it from you another way.

2. Functional and preferences — consent required

These remember choices you have made so that the Service behaves the way you left it: language, time zone, theme, layout, dismissed messages, and support or chat widgets where we offer them.

Refusing this category costs you convenience, not access. Everything still works; it simply forgets your preferences between visits and you set them again.

3. Analytics — consent required

These tell us how the Service is used: which pages and features are used, which paths people abandon, what is slow, and what fails. Depending on the surface this may include a provider's own persistent identifier and, where the table says so, a masked reconstruction of a session.

Third-party analytics tools are off until you turn them on, and nothing in this category loads before you choose.

There is one deliberate exception, and it is the subject of the next section: our own analytics, running on our own servers, is designed to operate without a consent requirement — cookieless, with no persistent identifier and aggregate reporting only. The next section sets out exactly what that involves and the conditions it depends on.

4. Marketing — consent required

These measure whether our marketing works and help us understand who is interested in the product: attribution of a sign-up to the campaign that produced it, and business-audience identification tools.

One of these deserves a plain sentence rather than a euphemism. Visitor identification tools resolve a visitor's IP address to the organisation it belongs to, so that we can see which companies have looked at the product. They do not tell us your name, but most people do not expect a website to work out their employer, so we would rather say it here than let you find it in a table. It is off unless you consent.

No cookie walls, ever

We do not use cookie walls, and we never make access conditional on consenting to non-essential cookies.

You can refuse everything except the strictly necessary category and the whole of the Service remains available to you — the same features, the same content, the same price. We do not offer a "consent or pay" alternative. We do not degrade the experience, hide content, or nag you on every page because you said no. Refusing is a decision we record and respect, not a negotiating position.

Ever Traduora: what runs on our two websites

This annex covers the two properties we operate under this name: the website at traduora.co and the documentation at https://docs.traduora.co. There is nothing else to cover. Ever Traduora is software you run on your own server — there is no hosted service, no sign-in and no application of ours holding anything of yours — so the parts of this policy written for a signed-in Service describe a surface that does not exist for this product.

The software we publish writes nothing to anybody's device on our behalf and reports nothing to us. It carries no analytics, no telemetry, no licence check and no update ping. What your own instance stores in your users' browsers to keep them signed in is yours to describe, on your own domain.

One absence is worth naming before the tables. We run no analytics of our own on these sites. There is no first-party, self-hosted measurement tool here, and therefore nothing that could rely on the audience-measurement exemption. Every measurement technology below belongs to another company, and every one of them waits for your consent.

1. The website at traduora.co

Two honest notes on that table.

• The Google Analytics identifier in our pages is a legacy Universal Analytics property. Whether or not anything is still measured behind it, loading the tag tells Google you were here, so it is declared and consent-gated like any other analytics tool rather than treated as dormant.
• New Relic's agent is configured with its own cookies switched off, so it stores nothing on your device. The beacon it sends is still a disclosure to that provider, which is why it sits in the analytics category with the rest.

Our Sub-processor List gives the full legal name, the location and the exact data set for each of these providers.

2. The documentation at https://docs.traduora.co

No analytics of any kind runs on the documentation. No Google Analytics, no product analytics, no session replay, no performance monitoring. The two sites genuinely differ on this point. It would be tidier to describe them as one, and it would not be true.

What is actually written to your device

Cookies are not the whole story, and a notice that lists only cookies under-describes what is happening. The rules that require your consent apply to storing or reading anything on your device, whatever mechanism does it. So, precisely:

• Cookies set by us — one holding a language code and nothing else, written when you use the language switcher on traduora.co; and the record of your consent choice.
• Cookies set by others — Cloudflare's own security cookies, lasting from the session up to a year depending on which one; Google Analytics' client identifier, up to two years; and PostHog's visitor identifier, up to a year.
• Browser local storage — your light or dark theme choice on both sites, and the sections you have collapsed in the documentation. These stay until you clear your browser's storage. PostHog also keeps its visitor identifier here as well as in a cookie.
• Browser session storage — the identifier that ties a session replay together. It is cleared when you close the tab.
• Nothing at all — New Relic's agent, the Pingdom measurement, the flag icons and the documentation typefaces. Each is a request that leaves your browser rather than something left behind in it.

Two requests that leave your browser before you have chosen anything

We would rather name these than let you find them.

The language menu on traduora.co loads its flag images from jsDelivr, a public content delivery network, and the documentation loads its two typefaces from Google. Nothing is stored on your device by either, but the request discloses your IP address, your browser and the page you are on to that network — and because both are needed for the page to render as designed, they happen whether or not you accept anything.

There is no way to fetch a file from somebody else's network and hide the request for it. The real fix is to serve both files ourselves, which is what the website already does for its own typefaces, and we intend to do the same for these two. Until then, the accurate statement is the one above rather than a claim that nothing loads before consent.

Session replay, in full

Our error diagnostics provider records session replays on traduora.co. A session replay is a reconstruction of your visit — the structure of the page, what moved, what you clicked, what you typed into, and in what order — played back afterwards like a recording.

• It is captured for roughly one visit in ten, chosen at random, and for every visit in which an error occurs.
• All text is masked and all media is blocked in the capture. What is reconstructed is the shape of the page and your interaction with it, not the words on it.
• It runs on the website only. There is no session replay on the documentation.
• It is in the analytics category and it is gated like everything else in that category. Refuse analytics and no replay is captured at all.

We give it its own section because recording a session is a different proposition from counting page views, and you are entitled to decide about it on its own terms rather than find it folded into a general line about error tracking.

What does not run on either site

• No advertising, no advertising pixel and no cross-site tracking. Nothing here is used to target advertising anywhere, and no advertising network receives anything from these pages.
• No visitor identification. We make no attempt to work out which organisation a visitor belongs to.
• No tag manager container. Google's tag is delivered from googletagmanager.com, which is that company's delivery host — but we operate no container through which further tags could be added without changing this document.
• No bot-protection script, because there is no form. There is no sign-up, no newsletter, no contact form and no checkout on either site, so no reCAPTCHA or equivalent loads and nothing about your mouse movement or typing is sent anywhere for that purpose.
• Nothing reaches our content management system from your browser. Our own server reads it when a page is built; your browser never contacts it.

If you run your own copy

This policy describes our two websites, not your instance. Ever Traduora ships with no analytics, no tracking technology and no consent mechanism of its own, so there is nothing of ours to switch off in a deployment you run — and equally, nothing of ours to ask your users about. If you add a measurement tool to your own deployment, telling your users about it and asking them where the law requires it is yours to do. Our banner is not your consent mechanism.

If you find something running on either of our sites that is not in the tables above, that is a defect and we want to know. Write to [email protected].

Third-party cookies and the providers behind them

Some of what runs on our pages belongs to other companies. We chose to include it, so we tell you it is there — but the provider decides what its own technology collects, and for that collection it is usually acting in its own right and under its own privacy notice rather than ours. Where that is the case, the table below links to their notice.

These are the kinds of provider involved, and what each kind does.

Analytics providers

Measure how the Service is used: page views, feature use, funnels, errors and performance. Most set a persistent identifier of their own so a returning visitor is recognised, and some can record a session replay — a reconstructed, masked playback of what happened on the screen. Where a tool on a surface can do that, the table says so explicitly.

Consent required. They do not load until you agree.

Tag management

A tag manager is a container we load once, through which other tags can then be delivered without shipping new code. That flexibility is exactly what makes it worth describing carefully: a container is a delivery mechanism, so what it delivers matters more than the container itself.

Every tag we deliver through a container is declared in the table below, in its own category. The container is consent-gated as a whole, and we do not use it to deliver anything from a category you have refused.

Consent required.

Marketing and visitor identification

Campaign measurement and attribution — which advertisement, email or article led to a visit or a sign-up — and business-audience identification, which resolves a visitor's IP address to the organisation that holds it so we can see which companies are interested in the product. It gives us a company, not your name. Most people still do not expect it, which is why it is named here as well as in the table.

Consent required.

Video, maps, fonts and other embedded content

Where a page embeds something served from another provider's network — a video player, a map, a code sandbox, a font, a script from a public content delivery network — your browser fetches it directly from that provider.

That fetch discloses your IP address, your browser and the page you were on to the provider, whether or not anything is stored on your device. There is no way to embed a resource and hide the request for it.

We handle this in two ways: where we can serve the asset ourselves, we do, which removes the third party entirely; and where an embed stores or reads anything on your device, we treat it as consent required and it does not load until you agree. Embeds that store nothing but are still fetched from a third party are listed in the table so you can see the disclosure even where no cookie is involved.

Security and delivery

The network in front of our sites — the proxy and content delivery layer that terminates the connection, absorbs attacks and filters hostile traffic — along with bot protection on forms and fraud checks on payment. These see connection metadata and may set their own security cookies.

Strictly necessary, and therefore not consent-gated. Our reasoning for putting bot protection in that category, including what it sends to its provider, is set out in the categories section above.

Measurement injected by that layer, which our banner cannot control

There is one thing here we would rather state plainly than have you discover in a network trace. Our content delivery provider injects its own lightweight measurement script at the edge — into the response, after it leaves our servers. It is not in our code, our consent system never sees it, and switching a category off in our preference centre does not stop it, because by the time the page reaches you the script is already part of it.

What it is: a page-view beacon operated by that provider. It sets no cookie, creates no persistent identifier of you, and reports aggregate traffic. It is not used for advertising and it is not joined to anything else we hold.

What it is not: covered by the exemption we claim for our own analytics. That argument rests on the data staying on our own infrastructure, and this is a third party receiving it. We are not going to stretch the same reasoning over both.

If you would rather it did not run, a content blocker or a network-level block stops it, and we do not attempt to detect or defeat that. You can also write to [email protected] and we will tell you the current provider and exactly what it collects.

Where these providers are, and where to find the full list

Some of these providers are established outside the European Economic Area, and using them involves an international transfer of personal data. The transfers section of our Privacy Policy sets out the destinations and the safeguards we rely on for each, and you can ask us for a copy of those safeguards.

Two lists keep this current, and between them they are the authoritative answer:

• The table in the product-specific section below names every cookie and similar technology in use on this product's surfaces — the provider, whether it is first- or third-party, its category, its purpose, how long it lasts, and a link to the provider's own notice.
• Our Sub-processor List covers the wider set of providers that process personal data for us, including the many that never touch your device at all. You can obtain the current version at any time from [email protected], and it names the sub-processor, what it does, and where it processes.

We update both when a provider is added, removed or changed. If you find something on our pages that is not in either list, tell us at [email protected] — that is a defect and we will fix it.

Consent, and how to withdraw it

How the banner works

On your first visit we show a consent banner, and nothing in the functional, analytics or marketing categories is written to or read from your device until you have made a choice. The strictly necessary items load, because the page cannot be delivered otherwise. Everything else waits.

The first layer of the banner — the one you see without clicking anything further — carries both a Reject all and an Accept all control, presented with equal prominence. Refusing everything takes one click, exactly like accepting everything. Alongside them is a route into per-category choice, so you can accept analytics and refuse marketing, or any other combination.

Three things that some banners do and ours does not:

• No pre-ticked boxes. Every category except strictly necessary starts switched off.
• Closing the banner is not consent. Neither is dismissing it, scrolling past it, or carrying on browsing. If you do not make a choice, nothing optional is set — you simply have not decided yet.
• No dark patterns. We do not make the reject control smaller, greyer, slower or harder to find than the accept control, and we do not hide it a layer down.

Changing your mind

Withdrawing consent is as easy as giving it, and you can do it at any time.

There is a persistent Cookie preferences link in the footer of every page, and an equivalent entry inside the application's settings. It opens the same per-category controls you saw in the banner, showing what you currently allow. Change a switch and it takes effect immediately: we stop, and where we can, we remove what was stored.

Two honest limits on that:

• Withdrawal works forwards, not backwards. It does not make lawful past processing unlawful, and it does not reach into data a third-party provider already received. If you want that deleted too, ask us at [email protected] and we will tell you who holds it and how to ask them.
• Your choice is stored on the device and browser you made it on. A different browser, a different device or a private window will ask again, because there is nothing there to read. Clearing your browser storage deletes the record of your refusal as well, which is why the banner reappears afterwards.

The record we keep

When you make a choice we record what you chose, when you chose it, which categories it covered, and which version of this policy was in force at the time. That record exists for two reasons: so that we honour your choice, and so that we can show what you were asked and what you answered.

You can ask us for a copy of your own consent record at [email protected].

How long a choice lasts before we ask again

We store a consent choice for six months. After that the banner appears again so you can confirm or change it. We will also ask again sooner if we add a purpose or a category your earlier choice did not cover, or if this policy changes in a way that materially affects what you agreed to.

This is our own practice, not a legal requirement. There is no EU-wide statutory interval for asking again — six months follows regulator guidance we consider sensible and proportionate, and we have chosen to apply it. If you would rather not be asked at all, refusing everything is a decision we keep for the same six months, and blocking storage at the browser level stops the question permanently.

Controls in your browser and on your device

Our banner is not the only way to control this, and it is not the strongest one. Your browser and your operating system can enforce a choice on every site at once, including ours.

In a browser

Every major browser — Chrome, Firefox, Safari, Edge and the rest — offers the same set of controls, under privacy or site settings:

• Delete cookies and site data, for one site or all of them.
• Block cookies, either all of them or only those set by third parties.
• Clear storage on exit, so nothing survives the session.
• Private or incognito windows, which discard everything when the window closes.
• Per-site permissions, so you can allow storage on the sites you use and block it everywhere else.

Your browser's own help pages describe exactly where these live in your version — we deliberately do not reproduce click-by-click instructions here, because they go stale faster than this document does.

Content blockers and privacy extensions work on our sites too. Using one is a legitimate choice, and we build the Service so that it keeps working when the optional things are blocked.

In our desktop and mobile applications

An installed application has no browser settings to change, so the controls are at the operating-system level instead:

• Reset or limit the advertising identifier your device provides.
• Answer no to the app-tracking permission prompt on iOS, which stops access to that identifier entirely.
• Withdraw notification permission, which stops the push token being useful.
• Clear the application's stored data, or uninstall it, which removes everything it kept locally.

The Cookie preferences controls described above are also available inside the application, and they govern the same categories there as on the website.

What breaks if you block the strictly necessary ones

Blocking the optional categories breaks nothing. Blocking storage entirely does, and you should know what to expect:

• You will not be able to sign in, or stay signed in. Authentication needs somewhere to keep the session.
• Forms may fail their security check and refuse to submit.
• Some features will behave inconsistently, because requests can no longer be kept on the same server.
• We cannot remember that you refused. The record of your choice is itself stored on your device, so blocking storage means the banner returns on every visit — the one genuinely irritating consequence, and it comes from the mechanism rather than from us being difficult.

Do Not Track

Browsers once offered a Do Not Track header, and some still do. We do not treat it, on its own, as a refusal — and we would rather explain why than quietly ignore it.

No consistent standard was ever agreed for what a site should do on receiving it. It was never clear whether it expressed a considered decision or a default someone else had set, browsers behaved differently, and several have withdrawn it. A signal we cannot interpret is not a safe basis for deciding what you want.

Use the banner or the preference centre instead. A choice made there is unambiguous, and we record it.

Global Privacy Control

Global Privacy Control (GPC) is the later, better-specified signal, and unlike Do Not Track it is defined to express an actual opt-out rather than a preference.

Where we receive a GPC signal from your browser, we treat it as a refusal of the analytics and marketing categories on that browser, and we act on it without waiting for you to interact with a banner.

Two points of detail:

• It applies to the browser or device sending it. Another browser sends its own signal, or none.
• An explicit choice you make later in our preference centre takes precedence, in either direction. If you switch a category on there while GPC is enabled, we treat that as your decision, and we record it as such. If you would rather that never happened, leave the categories switched off.

Changes to this policy

We update this policy when what we do changes — a provider added or removed, a technology retired, a category reassigned. Every update gets its own version number and effective date, recorded at the end of this document.

Where a change materially affects what you agreed to — a new purpose, a new category, or a tool moving out of the strictly necessary or exempt group — we ask for your consent again rather than relying on the choice you made against the old text. Corrections, clarifications and provider renames are published with a new version and no fresh request.

Earlier versions stay available, with the dates each was in force, at https://traduora.co/cookies. The effective date shown with this policy tells you which version applies today.

How to reach us

Questions about this policy, about anything in the table above, or about a choice you have made — write to [email protected]. That address is monitored and we answer it. Ask us for a copy of your own consent record, for the current sub-processor list, or to be excluded from our own analytics, and we will do it without asking why.

By post: Ever Technologies LTD, Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria — registered in Bulgaria under company number 204599535. We correspond in English.

If you think we have handled your data badly, tell us first — we would rather fix it. You can also complain to a data protection supervisory authority at any time. Ours is the Commission for Personal Data Protection (Комисия за защита на личните данни), the CPDP, at https://www.cpdp.bg/. You may instead complain to the authority for the country where you live or work.

This document is version 1.0.2 of the Cookie Policy for traduora.co, in force from 2026-08-02. Earlier versions, with the dates they applied, are at https://traduora.co/cookies.