Privacy Policy

Ever Traduora — traduora.co

Version 1.0.2 · In force from 2026-08-02

This notice explains what we do with personal data when you use Ever Traduora and the websites, applications and application programming interfaces we make available at traduora.co (together, the "Service"). It tells you what we collect, why, who else sees it, how long we keep it, and what you can ask us to do about it.

We have written it to be read rather than to be defended. Where something is uncomfortable — data we hold that you never gave us, or data your employer decides to collect through our software — we say so plainly instead of burying it in a list.

What this notice covers

• The website at traduora.co and the pages served from it.
• The Ever Traduora web application, together with any desktop application, mobile application or browser extension we publish for it.
• The application programming interfaces and integrations we operate for it.
• The emails, notifications and support conversations that go with it.

A product-specific annex appears later in this notice. It adds detail for Ever Traduora — what it actually collects, what is switched off by default, and which controls exist. It sits on top of this notice rather than instead of it, and where it is more specific about Ever Traduora, the annex governs.

What this notice does not cover

Other companies' products. Other companies operate their own websites, products and services, and publish their own privacy notices. This notice covers only what is listed above. If a service is not on that list, this notice does not apply to it — whatever it looks like, and whoever links to it.

Software you run yourself. Some of our software is published as open source and can be installed on your own infrastructure. If you run your own deployment, you are the controller of the personal data in it — not us. You choose its hosting, its storage, its email provider and every other component. We have no access to that data, we do not process it, we are not your processor for it, and nothing in this notice describes it. Telling your own users what happens in your deployment is your job, not ours.

Sites we link to. The Service links out to third-party websites and services. Once you follow a link away from us, the operator of that site decides what happens to your data. We do not control those sites, we do not receive what you do on them, and we are not responsible for them. Read their notices, not this one.

Your organisation's own systems. Where your employer or another organisation uses the Service, it also runs systems of its own. This notice covers our part. Its notice covers its part.

Who we are

The controller of the personal data described in this notice is Ever Technologies LTD, a company registered in Bulgaria under company number 204599535, with its registered office at Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria.

"Controller" is the legal term for the organisation that decides why personal data is used and how. Wherever this notice says we make that decision, Ever Technologies LTD is the organisation accountable to you — and to the Commission for Personal Data Protection (Комисия за защита на личните данни) (CPDP), which is our lead supervisory authority.

Ever Technologies LTD operates Ever Traduora and is the company you contract with for it. There is no other operator behind us and no second company you have to chase to get an answer.

You can reach us about anything in this notice at [email protected], or by post at the registered office above.

There are parts of this notice where we are deliberately not the controller: where a customer puts personal data about its own people into the Service, that customer decides, and we act on its instructions. That split matters, so it has its own section below.

Other companies in our group

There is one other company in our group, and its role is narrow enough to state in a sentence.

Ever Co. LTD, a company registered in Israel under company number 515241842, with its registered office at HaAtsmaut 32/3, Ashdod 77452, Israel, owns the intellectual property in the software. Ever Technologies LTD operates the Service under licence from it.

That is the entire relationship. Its consequences are worth stating positively rather than leaving you to work them out:

• Ever Co. LTD does not access personal data held in the Service. No administration console, no production database, no support tooling, no backups, no error reports.
• It is not a controller of that data, not a processor of it, and not a sub-processor. It does not appear on our sub-processor list, because there is nothing for it to appear against.
• No personal data is transferred to it. No international transfer to Israel arises out of your use of the Service, because none happens.

Owning software is not the same as having access to the data that software holds, and we have kept the two apart on purpose.

If that ever changes — if Ever Co. LTD were to take on any role involving personal data from the Service — we would update this notice before it happened, name the role, disclose the transfer and the safeguard we relied on, and add it to our sub-processor list. Until you read that here, none of it is happening.

Data protection contact

We have not designated a Data Protection Officer. Article 13(1)(b) of the GDPR asks a controller to publish a Data Protection Officer's contact details where one has been designated. None has been designated at Ever Technologies LTD, so there are none to publish. We would rather tell you that outright than let a mailbox name imply otherwise. We keep the question under review, and if it changes we will publish the details here.

What we do publish is a contact route that is monitored and acted on. Privacy questions and requests to exercise your rights are handled through these addresses:

• [email protected] — use this for anything about this notice, about the personal data we hold, or to make a request under any of your rights.
• [email protected] — an alias that reaches the same people. It exists because procurement forms, security questionnaires and privacy tooling routinely expect an address in that form. It is a routing alias, not an office. Nothing about it means a Data Protection Officer has been designated.

You can also write to us by post at the registered office given above.

We will acknowledge your message, and we will answer a request to exercise your rights within one month — the deadline the GDPR sets. Where a request is genuinely complex, or where you have made several, we may extend that by up to two further months. If we do, we will tell you inside the first month and explain why.

Who decides what: controller and processor

Data protection law splits responsibility in two. The controller decides why personal data is used and how. The processor only acts on the controller's instructions. Which of the two we are is not a formality — it decides who you go to, who has to answer you, and who is accountable when something goes wrong.

Our position depends on whose data it is. There are three cases. We set them out here, in the privacy notice, rather than leaving them to a data processing agreement, because the person most affected by the second case is usually the person least likely to read a contract.

1. Our own relationship with you — we are the controller

Where we decide, we are accountable. We are the controller for:

• registration and account identity — the name, email address and credentials used to create and hold an account;
• billing, payments, invoices, tax records and collections;
• support conversations, including the tickets, emails, chats and attachments themselves;
• security, fraud prevention, abuse handling and audit logging;
• our own websites and their analytics, our newsletters, and our marketing to prospective customers; and
• running our business — accounting, insurance, professional advice, and defending claims.

Everything in this notice about purposes, legal bases, retention, transfers and your rights applies to this first case directly, and you exercise those rights against us.

2. Personal data a customer puts into the Service about its own people — the customer is the controller

When an organisation subscribes to the Service and uses it to run its business, the personal data it puts in is its data. It decides what to collect, which features to switch on, why, and for how long to keep it. We process that data only on that organisation's instructions. For it, the organisation is the controller and we are the processor.

This covers the ordinary contents of a workspace — employee and contractor records, contact details, projects, tasks, documents and messages. It also covers the parts that matter most, where a product provides them and the customer has enabled them:

• time-tracking data — timers, timesheets, time entries and the records behind them;
• activity data — how much keyboard and mouse activity occurred in a period, idle time, and which applications and websites were in use;
• screen and media capture — periodic screenshots and, where separately switched on, webcam stills, audio recordings and screen recordings.

We do not decide to collect any of this. The customer does. We build the features, we document what each one captures and what each control does, and we run them exactly as the customer configures them. We do not use that data for our own purposes, we do not use it to train models, and we do not look at it except where we must in order to run, secure or support the Service.

What Ever Traduora can capture, what is off by default, and which controls exist is set out in the annex later in this notice.

3. Data a customer holds about its own clients and end users — the customer is the controller

Where a customer uses the Service to serve its own clients, members, applicants, patients or website visitors, that data sits in the same arrangement as case 2. The customer is the controller, we are the processor, and the customer owes those people the notice and the answers. If you have dealt with an organisation and want to know what it holds about you, ask that organisation.

If you are monitored at work, this part is for you

We would rather tell you directly than make you work it out from a contract you have never seen.

Your employer decides what is captured. We do not. Screenshots, activity rates, application and website usage, webcam stills, audio, screen recordings — each of these is a setting your employer switches on or leaves off, for the organisation and, where the product allows it, for individual people. We cannot switch them on for your employer, and we do not switch them on for ourselves.

Your employer is the controller of that data. That means your employer, not us:

• must have a lawful basis for monitoring you, under the GDPR and under its own national employment law, which differs sharply from country to country;
• must tell you, before it starts, what is captured, how often, why, and how long it is kept;
• must carry out a data protection impact assessment where one is required, and act on what it finds;
• must consult a works council, employee representatives or a trade union where its national law requires that; and
• must answer your requests about that data.

We make no claim that monitoring employees is lawful across the European Union, because it is not. Some countries restrict it tightly, some require consultation before it starts, and some prohibit particular forms of it outright. Whether your employer's use of these features is lawful where you work is your employer's responsibility. We require every customer to confirm to us that it has dealt with each of the points above before it uses these features.

How to exercise your rights over monitoring data. Send your request to your employer — it holds the data and it has to answer you. If you send it to us instead, we will not ignore it:

• we will forward it promptly to the customer whose workspace holds the data;
• we will tell you that we have done so, and to whom, so you are not left waiting on silence; and
• we will help that customer find, correct, export or delete the data, which is what our contract with it requires of us.

What we will not do is release one organisation's data to someone else on request. We cannot verify an employment relationship from the outside, and handing over a workspace's contents to a person the customer has not authorised would be a breach in its own right. That restraint protects you as much as it constrains you.

If you think your employer is monitoring you unlawfully, you can complain to the data protection authority in your own country, and to your national labour authority. You do not need our permission, and you do not need to come through us first.

Personal data we collect

We group this by where the data comes from, because that is what determines what we know about you and what we owe you.

Not every category applies to every product, plan or user. This section describes the shape of what we collect; the annex later in this notice lists what Ever Traduora actually collects.

What you give us

• Account identity — your name, username, email address, password (held only as a hash), profile picture, job title, preferred language and time zone.
• Organisation details — the organisation you belong to, your team, your role and permissions within it, and who invited you.
• Contact details — email address, telephone number and postal address, where you provide them.
• Billing details — billing name and address, VAT or tax identification number, the plan you are on, invoices and payment history. We do not receive or hold your full card number — that goes straight to our payment processor.
• Support correspondence — the tickets, emails, chat messages, screenshots and files you send when you ask for help, and our replies.
• Content you submit — everything you or your organisation puts into the Service: documents, tasks, projects, records, messages and uploads. Where that content belongs to your organisation, we hold it as processor, not as controller.
• Anything else you volunteer — survey answers, feedback, event registrations, newsletter sign-ups, and whatever you choose to write to us.

What we collect automatically when you use the Service

• Device and browser data — device type, operating system, browser and version, screen size, language, and the version of our application you are running.
• Connection data — your IP address, and the approximate location it indicates. That is city-or-region level, derived from the IP address, and it is not satellite positioning. Where a specific feature collects precise location, it says so.
• Usage data — pages and screens viewed, features used, actions taken, navigation paths, timestamps and the page that referred you.
• Logs — server and application logs of requests, errors, response times, sign-ins, failed sign-ins and administrative actions, with the identifiers needed to tie an entry to an account.
• Diagnostics — crash reports, stack traces and performance traces. These can incidentally contain whatever was in the request that failed.
• Cookies and similar technologies — cookies, local storage, pixels, software development kit identifiers and comparable device storage. What each is for, and which ones need your consent, is in our Cookie Policy.

What we receive from other people

• Identity providers — if you sign in with a third-party account, we receive that account's identifier, your email address, your display name and usually your profile picture, plus confirmation that the sign-in succeeded. We never receive your password for it.
• Payment processors — whether a payment succeeded or failed, the payment method type, the last four digits and expiry of a card, the billing country, and any dispute or chargeback.
• Integrations you or your administrator connect — whatever the connected service returns within the permissions granted. That varies by integration and is shown to you when you authorise it.
• Your organisation — where an administrator creates your account, invites you, sets your role or imports records about you.
• Other sources, where a particular product uses them. Those are set out in the next section and in the annex.

What you have to give us

Some of it is unavoidable. Without account identity we cannot create an account for you; without billing details we cannot take payment for a paid plan; without certain records we cannot meet our own legal obligations. Where data is necessary in that sense, not providing it means we cannot provide that part of the Service — but nothing worse follows.

Everything else — an optional profile field, a newsletter subscription, an integration you could simply not connect — is genuinely optional, and declining it costs you nothing.

Data we do not collect

Shorter than the previous section, and just as binding. These are commitments about how the Service is built, not aspirations.

• We do not sell personal data. Not to data brokers, not to advertisers, not to anyone — and not under the broader definitions of "sell" or "share" used outside the European Union.
• We do not buy marketing lists. If we contact you about our products it is because you gave us your details, or because you are already a customer. We do not purchase your name from someone else in order to email you.
• We do not use your content to train machine-learning models — not for our own purposes, and not for the benefit of other customers. Where a product has an AI feature, it processes your content to produce your result, and that is the end of it. If we ever want that to change, it will be an opt-in you actively choose, described before you choose it.
• We do not run advertising inside the Service. No third-party advertising, no behavioural ad targeting, no cross-site advertising identifiers in the product.
• We do not record what you type. Where a product measures keyboard and mouse activity, it counts events over a period. There is no keylogger in our software. The content of your keystrokes is never captured, stored or transmitted.
• We do not ask for special-category data — health, racial or ethnic origin, religious or philosophical beliefs, political opinions, trade union membership, sex life or sexual orientation, genetic or biometric data. There are no fields for it, we do not infer it, and we do not want it. The one honest caveat is about what can end up inside a screenshot, and it has its own section below.
• We do not store full card numbers or card security codes. Those are entered on our payment processor's systems and never reach ours.
• We do not collect precise location by default. Where a product uses location at all, it is because a specific feature needs it, and that feature says so.

If you find any of this to be untrue of something we ship, tell us at [email protected]. We will treat it as a defect in the product, not as a disagreement about wording.

Where data comes from when it does not come from you

Not all of the personal data we hold came from you. Article 14 of the GDPR requires us to tell you where it came from, and this section does that.

• Your employer, or the administrator of your workspace. Where an organisation subscribes to the Service, an administrator creates accounts, invites people, sets roles and imports records. That supplies your name, work email address, job title, team, role and permissions, and whatever else the organisation chooses to hold about you in its workspace. For that data the organisation is the controller, as set out above.
• Identity providers. If you sign in with a third-party account, that provider supplies the account identifier, your email address, your display name and usually a profile picture, and confirms the sign-in succeeded. It supplies nothing else, and never a password.
• Integrations you or your administrator connect. A connected service supplies whatever the permissions you granted allow — for example issues and repositories from a code host, messages and channel names from a chat tool, calendar entries, contacts, or records from another business system. The scope is shown when the connection is authorised, and it can be revoked in the same place.
• Payment processors and resellers. They supply the outcome of a payment, the payment method type, the last four digits and expiry of a card, the billing country, and any dispute or chargeback. They do not pass us the card itself.
• Publicly available sources, where a product builds profiles from them. Some products work with information people have published themselves — a public code-hosting profile, a public company page, a public professional listing. Where a product does this, the annex names the categories taken and the sources they came from, explains the basis we rely on, and says how to object. If we hold a profile about you that you never gave us, you can object to it and we will act on that.
• Service providers acting for us. Fraud and abuse signals, delivery and bounce information from the systems that send our email, and security intelligence about addresses and networks.

Where we are the controller of personal data that did not come from you, we will tell you within a reasonable period and at the latest within one month of obtaining it — or, if we use it to contact you, at that first contact. Where informing every individual separately would take disproportionate effort, this notice and its annex are the public information we provide instead, which is what Article 14(5)(b) allows.

Why we use personal data, and on what legal basis

Article 6 of the GDPR requires a lawful basis for each purpose. So this is one row per purpose, rather than a general list of all six bases — you can check us against each line.

Two things this table deliberately does not cover.

Where we act as processor, the lawful basis is not ours to pick. The customer that put the data into the Service decides the purpose and must have its own basis for it. See the controller and processor section above.

Where we rely on your consent, you can withdraw it at any time, and withdrawing it is as easy as giving it. Withdrawing consent does not make earlier processing unlawful — it stops the processing from that point on.

The legitimate interests we rely on

Where the table above says "legitimate interests", the law requires us to tell you what that interest actually is — not simply to name the basis and move on. For each one we have asked three questions: what is the interest, is the processing genuinely necessary for it, and is it fair to you. That last question is the balancing test, and we keep a written record of it.

Keeping the Service and its users secure

• The interest: preventing unauthorised access, account takeover, fraud, spam, denial-of-service and abuse of the Service.
• Why the processing is necessary: you cannot see an attack without looking at the traffic. Sign-in records, IP addresses, device data and request logs are what make an intrusion visible at all.
• Why it does not override your rights: the data is limited to what security work needs, it is kept for a bounded period, and the benefit goes to the same accounts and the same people whose data is used. Nobody reasonably expects a service to be run without security logging.

Keeping the Service running

• The interest: operating a reliable service — monitoring, error tracking, debugging, capacity planning and backups.
• Why the processing is necessary: faults surface in logs, and a crash report is only useful if it records what was happening when the crash occurred.
• Why it does not override your rights: it is operational data, kept for short periods, used to fix software rather than to form views about people, and reachable only by the staff who need it.

Understanding how the Service is used

• The interest: knowing which features are used, where people get stuck, and what to build or fix next.
• Why the processing is necessary: the alternative is guessing. Aggregate usage data is the only practical way to see this without interrogating every user.
• Why it does not override your rights: we analyse it in aggregate rather than to make decisions about you individually, and wherever cookies or similar device storage are involved we ask for your consent instead of relying on this interest at all.

Answering people who write to us without an account

• The interest: replying to a question from someone who is not a customer.
• Why the processing is necessary: we cannot answer you without keeping your message and your address.
• Why it does not override your rights: you chose to contact us, we use it only to answer, and we keep it no longer than the matter and any follow-up require.

Telling existing customers about our own similar products

• The interest: letting people who already buy from us know about the products next to the one they bought.
• Why the processing is necessary: it uses the address they gave us during that sale, and there is no less intrusive way to reach them.
• Why it does not override your rights: it is confined to our own similar products, every message carries a one-click opt-out, and an opt-out is acted on immediately and permanently.

Running and protecting our business

• The interest: accounting, audit, insurance, professional advice, complaints, disputes, enforcing our terms, and evaluating or completing a corporate transaction.
• Why the processing is necessary: these are ordinary obligations of operating a company, and each one needs the records that relate to it.
• Why it does not override your rights: the data is confined to the matter in hand, access is narrow, and a great deal of it we are required to keep in any event.

Your right to object

You can object to any processing we base on legitimate interests, at any time, by writing to [email protected]. Tell us which processing, and where you can, why — your particular situation is part of the balance. We will stop unless we can show compelling legitimate grounds that override your interests, rights and freedoms, or unless we need the data to establish, exercise or defend legal claims.

If you object to direct marketing there is no balancing at all. We stop. That right is absolute.

You can also ask us for a summary of the balancing test behind any interest listed above, and we will give you one.

Special categories of data

Some personal data carries extra protection under Article 9 of the GDPR: data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, and genetic data, biometric data used to identify someone, data concerning health, and data about a person's sex life or sexual orientation. Data about criminal convictions and offences is restricted separately, under Article 10.

We do not seek any of it. We do not ask for it at sign-up, in billing or in support. There are no fields for it, we do not infer it, and we do not enrich profiles with it. Please do not send it to us in a support ticket either — if you need to show us something sensitive to get help, redact it first.

The honest caveat: incidental capture

Where a customer switches on screen capture, webcam capture or audio capture, what gets captured is whatever is there. A screenshot taken while someone has a hospital appointment email open captures health data. A webcam still can show a religious head covering. An audio recording can pick up a background conversation that has nothing to do with work.

That is not a theoretical risk and we will not present it as one. It is a direct consequence of capturing a screen or a room on a timer, and it is true of every product that does it, ours included.

Whose responsibility it is

The customer that switches these features on is the controller of what they capture, including anything special-category that comes with it. So the customer, not us:

• decides whether to enable capture at all, and has to judge whether the benefit justifies the intrusion;
• must carry out a data protection impact assessment before starting, and act on what it finds — capture of this kind will normally require one;
• must have a lawful basis, and where special-category data is realistically in scope must also satisfy Article 9(2), which an employee's consent rarely does on its own, because of the imbalance between employer and employee;
• must configure the product to reduce that risk rather than accept it; and
• must deal with what has been captured, including deleting a capture that should never have been taken.

We are the processor for it. We do not decide to capture anything, we do not review captures for our own purposes, and we act on the customer's configuration and instructions.

The levers, and using them

Where a product offers screen or media capture, it also offers controls that materially reduce this risk. Depending on the product, those include:

• switching capture off entirely, for the whole organisation or for an individual person;
• switching off the more intrusive capture types — webcam stills, audio and screen recording — while keeping the rest;
• reducing how often captures are taken;
• blurring captured images;
• shortening how long captures are kept, and deleting them automatically at the end of that period;
• letting people see what has been captured about them; and
• deleting an individual capture.

If you are a customer, these are yours to set, and the defaults are not a recommendation. Choose the least intrusive configuration that meets the purpose you actually have, and write down why you chose it. That record is what a supervisory authority will ask for.

If you are being monitored and something sensitive has been captured, ask your employer to delete it. Your employer can do that in the product. If you tell us instead, we will forward your request and help your employer act on it, as described in the controller and processor section above.

Which of these controls Ever Traduora provides, and what its defaults are, is set out in the annex later in this notice.

Ever Traduora: what we actually process

We host nothing for Ever Traduora, so there is no data of yours for us to hold. There is no cloud version, no sign-in, no workspace and no database of yours on our side. Of the three cases set out in the controller and processor section above, only the first applies to this product: we are the controller for what happens on our own websites, and for nothing else. We are not your processor for Ever Traduora, and there is no data processing agreement to sign for it, because there is no processing of yours for us to agree to.

Ever Traduora also has no monitoring features of any kind — no screenshots, no activity measurement, no application or website tracking, no location, no webcam, no audio and no screen recording. The passages above about monitored workers describe other products in our range. They have nothing to describe here.

So this annex has two parts.

• Part A is what we process when you visit our websites. That is the whole of our processing for this product.
• Part B is what the software processes on your server. It is here so that you can build your own notice from it, and so that it is unmistakable that none of it reaches us.

Part A — visiting traduora.co and docs.traduora.co

There is no account on either site, nothing to sign in to, nothing to buy, and no content of yours to store. What we process is the visit itself.

• Connection data — your IP address, the approximate region it indicates, and the TLS and connection metadata that comes with any web request. This reaches our edge network provider before it reaches us.
• Device and browser data — user agent, browser and version, operating system, screen size and language.
• Page data — the pages you viewed, the page that referred you, and timestamps.
• A product analytics identifier — a persistent identifier generated by our analytics provider, with a page-view event and a page-leave event for each page.
• A web analytics client identifier — a first-party cookie set by Google Analytics.
• Performance measurements — page load and rendering timings, collected by two separate monitoring tools.
• Error diagnostics — where something on the page fails, an error event with a stack trace, the page it happened on and your browser details.
• Session replays — described in full immediately below, because a list entry does not do it justice.
• Your own preferences — the language you chose, stored in a first-party cookie, and your light or dark theme choice, stored in your browser's local storage.

Our Cookie Policy names each of these technologies individually, says which provider is behind it, and gives what it writes to your device.

Session replay, stated properly

Our error diagnostics tool 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.

The honest detail, rather than a line about error tracking:

• 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 goes to our diagnostics provider, named in the sub-processor tables, in the United States.
• It is in the analytics category, and it is subject to consent like everything else in that category. Refuse analytics and no replay is captured at all.

We disclose it separately because session recording is a different proposition from counting page views, and a reader is entitled to decide about it on its own terms rather than find it folded into a general statement about diagnostics.

What we do not do on these sites, though you might reasonably assume otherwise

• Fonts are not fetched from Google. They are compiled into the site when it is built and served from our own domain. Visiting our pages sends nothing to a font provider.
• The star count shown on traduora.co is fetched by our own server, not by your browser. Loading the page tells GitHub nothing about you.
• There is no newsletter and no mailing list for this product. We do not collect an email address anywhere on these sites.
• There is no advertising, no advertising pixel and no cross-site tracking, and none of the data above is sold, shared for advertising, or used to build a profile of you.

Legal bases for Part A

Two, and they divide cleanly.

• Consent — Article 6(1)(a). Every third-party analytics, performance and diagnostics tool named above, including session replay. Nothing in that group runs before you choose, and refusing costs you nothing on a site with no sign-in and no features to degrade.
• Legitimate interests — Article 6(1)(f). Delivering the pages, keeping the sites available, and protecting them from automated abuse at the edge. That covers the connection data our edge provider necessarily sees and the server-side request logs behind it, and no more.

Who receives it, and where it goes

Six providers, and no others: our edge network provider, our product analytics provider, our diagnostics and session replay provider, two performance monitoring providers, and Google for Google Analytics. Each is named, with what it does and what reaches it, in our Sub-processor List.

Most of them are established in the United States, and the transfers section of this notice describes the mechanism we rely on. One is different and we would rather be precise than tidy: our browser performance agent reports to that provider's European Union endpoint, so those measurements do not leave the EU even though the provider itself is a US company.

How long we keep it

There is no account here, so there is no account data with a retention period. What there is:

• Error events, session replays and performance data are diagnostics, and they are kept for the diagnostics period in the retention table above.
• Server-side request logs are kept for the log period in the same table.
• Analytics data sits with each provider under a retention setting. Where that setting is ours to make, we set it; write to [email protected] naming a provider and we will tell you the value in force.

Part B — what the software processes on your own server

None of the following reaches us. Ever Traduora contains no telemetry, no usage reporting, no licence check and no update ping. An instance you run never calls home, and we could not read it if it did.

We set it out anyway, because a deployer has to write their own privacy notice and this is the map.

• Users — name, email address, hashed password, password-reset token and its expiry, count of failed sign-in attempts, last sign-in time, number of projects created, and creation and modification timestamps.
• Invitations — the email address of someone a project or instance administrator invites, the status of that invitation, and the role attached to it.
• API clients — the machine credentials a project issues: name, role and secret.
• Content — projects, labels, term keys, the optional context notes attached to them, and translation values in every locale.
• Server logs — where access logging is switched on, the IP address, user agent, URL and status of each request; and per-IP counters used for rate limiting, whether or not access logging is on.
• Optional Google sign-in — where the deployer enables it, the Google account identifier, email address and display name of each user who uses it.
• Outbound email — welcome, password-change, password-reset and invitation messages, sent through the deployer's own mail relay.

Two categories of person who never agreed to any of this

Both live entirely on the deployer's server. Both are the deploying organisation's responsibility, under Articles 13 and 14 of the GDPR, and neither is ever visible to us.

• People who are invited. An administrator types an email address in, and from that moment the instance holds personal data about someone who has no relationship with it yet and may never accept.
• People named inside translation strings. A translation value is unconstrained free text. Product copy, email templates and sample data routinely carry real names, real email addresses and real postal addresses, and they end up in the database like any other string. Anyone exporting or importing that content is moving personal data whether they meant to or not.

If you run an instance, both of those are yours to notify and yours to answer for. Nothing in this notice describes your instance, and our banner is not your consent mechanism.

No machine translation and no AI, today

Ever Traduora does no machine translation and no artificial intelligence inference of any kind. It sends no translation content to any third party. That is a plain statement about the software as it is published, not a positioning claim, and it is unusual enough in this category to be worth stating.

If that changes, these are the commitments we are making now rather than after the fact:

• machine translation or AI will be switched on per project by the person running the instance, never on by default;
• each engine will be named, with its function stated, in the sub-processor list — not buried among infrastructure vendors — and marked as engaged only where somebody has enabled it; and
• content will not be used to train models, ours or anybody else's.

Community channels

The project's repository, issue tracker and chat community are operated by GitHub and by Discord on their own platforms. When you post there, you are dealing with them and their privacy notices apply, not this one. We read what is posted publicly, in the same way anyone else can.

The supervisory authority for this processing

Everything in Part A is processed by Ever Technologies LTD in Bulgaria, and the authority to complain to is the Commission for Personal Data Protection (Комисия за защита на личните данни) — https://www.cpdp.bg/. You can also complain to the authority where you live.

Cookies and similar technologies

Cookies, local storage, pixels, software development kits and similar technologies get their own document, because they need more detail than a summary can carry. What each one is, what it does, how long it lasts, who operates it and how to refuse it is set out in our Cookie Policy.

In short, we sort them into four categories:

• Strictly necessary — needed to deliver what you asked for: signing you in, holding your session, routing traffic, remembering your cookie choice itself, and protecting forms and sign-in against automated abuse. These are not optional, and we do not ask for consent to them.
• Preferences — remember choices you have made, such as language, region and interface settings.
• Analytics — help us understand how the Service is used so we can improve it.
• Marketing — measure our campaigns and help us understand which organisations take an interest in us.

Nothing in the preferences, analytics or marketing categories is placed or read on your device until you agree to it. You can accept everything, refuse everything, or choose category by category, and refusing takes exactly as few clicks as accepting.

Changing your mind

Your choices are not permanent. A Cookie preferences link sits in the footer of every page on traduora.co and reopens the same panel you saw the first time. Change a category there and it takes effect immediately, for the future. Withdrawing is as easy as agreeing, and nothing about the Service is withheld from you for refusing.

One analytics tool runs without consent, because it is configured so that it stores and reads nothing on your device and never builds a persistent identifier for you. That is a conditional position, not a permanent one: the Cookie Policy names the tool, describes the exact configuration we rely on, and says what happens if any part of that configuration ever changes.

Who receives your personal data

We disclose personal data only to the categories of recipient below, and only as much as each one needs to do the job it is there for.

• Service providers acting as our processors — hosting and infrastructure, storage, content delivery, email delivery, error monitoring, product analytics, customer support tooling and similar. They act on our documented instructions under a written contract that meets Article 28 GDPR, they are bound to confidentiality and appropriate security, and they may not use your data for their own purposes.
• Payment processors — to take payment, issue invoices and handle refunds and disputes. For their own regulated obligations — fraud prevention, anti-money-laundering, card-scheme rules — they act as controllers in their own right, and their own privacy notice governs that part.
• Professional advisers — lawyers, accountants, auditors and insurers, bound by professional confidentiality, where we need advice or have to evidence that we have complied with something.
• Public authorities, courts and regulators — where the law requires us to disclose, or where we need to establish, exercise or defend a legal claim. We check that a request has a proper legal basis and is no wider than it needs to be, we push back where it is not, and we tell you about it unless we are legally prohibited from doing so.
• An acquirer or successor — if we are reorganised, merged or sold, or if part of the business changes hands, personal data may pass to the acquirer as part of that transaction. The acquirer is bound by this policy or by a notice at least as protective, and we will tell you before anything about the handling of your data changes.

The sub-processors we engage for the hosted Service

These providers are engaged for the hosted Service as it is delivered to everyone. They are the ones your data is most likely to reach.

The full and current list, including everything below, is published at https://traduora.co/subprocessors, together with the notice period and objection procedure that apply when we add or replace one.

Three tiers, and why the difference matters

A single flat list of every vendor that appears anywhere in our software would be both inaccurate and misleading, so the sub-processor page is split into three tiers. They mean genuinely different things.

• Always engaged. The providers above. If you use the hosted Service, these are in the path.
• Engaged only if you turn something on. Optional integrations, connectors and features. A provider in this tier is engaged only when you or your workspace administrator enables the specific feature or connects the specific account it belongs to. Enable nothing and it is never involved. The list says which feature or setting activates each one.
• Self-hosted deployments only. Several of our products are published as open source and can be run on your own infrastructure. In that case you choose the database, object storage, email relay, AI provider and everything else, using your own credentials. Those providers appear in the list so you can see what the software can be pointed at — but they are your providers, not ours. We process nothing in a deployment you run, we are not your processor for it, and the commitments in this policy do not describe it.

We do not sell your personal data

We do not sell personal data, and we do not share it for cross-context behavioural advertising. We do not supply it to data brokers, we do not trade it for services, and we do not permit any provider we engage to use it to build advertising or interest profiles, on our sites or anywhere else.

Sending personal data outside the EEA

Most of the personal data we hold stays inside the European Economic Area, on infrastructure we operate ourselves. Some of it does not: a number of the providers we engage are established outside the EEA — principally in the United States — and some of them route, cache or store data on servers outside it.

Where that happens, the transfer needs a lawful mechanism under Chapter V GDPR. We use one of the following for every transfer, and the sub-processor page names the destination country and the mechanism provider by provider.

Adequacy

Where the European Commission has decided that a country provides an adequate level of protection, the transfer relies on that decision and needs nothing further. Adequacy decisions are kept under review by the Commission and can be amended, suspended or repealed, so we monitor them rather than treat them as permanent.

Providers in the United States

For a US provider we rely on one of two things.

• The EU–US Data Privacy Framework, but only where that provider is actively self-certified under it for the type of data concerned. We check the official Data Privacy Framework list when we engage a provider and re-check it periodically. We do not claim the Framework for a provider that has not certified, or whose certification has lapsed.
• Standard Contractual Clauses — the clauses approved by the European Commission in Implementing Decision (EU) 2021/914, with the modules that match the relationship, together with a transfer impact assessment and supplementary measures: encryption in transit and at rest, minimising what is sent in the first place, contractual limits on onward disclosure, and a commitment from the provider to notify and where possible challenge a government access request.

We keep Standard Contractual Clauses in place as the standing mechanism, including for providers that are also certified under the Framework. That is deliberate, and here is the honest reason.

The Commission's adequacy decision for the Framework, adopted on 10 July 2023, is currently valid. It was challenged, and on 3 September 2025 the General Court of the European Union dismissed that challenge in Latombe (Case T-553/23). That is not the end of it — an appeal is pending before the Court of Justice as Case C-703/25 P, and the two arrangements that preceded this one were each struck down by the same court. So we treat the Framework as a mechanism under review rather than a settled answer, and we keep a second mechanism standing behind it so that a change in the law is a paperwork event for us and not an interruption for you.

Other countries

For a transfer to any other country without an adequacy decision, we use Standard Contractual Clauses with the same assessment and supplementary measures. Where a transfer is to the United Kingdom or Switzerland, the corresponding UK and Swiss additions are applied to those clauses.

We rely on an Article 49 derogation — for example, a transfer that is strictly necessary to perform a contract you have asked us to perform — only in a specific, occasional case where no other mechanism fits. It is not a routine mechanism for us, and we do not use it to run a regular data flow.

Getting a copy of the safeguards

You are entitled to see the safeguards we rely on. Write to [email protected] naming the provider or the transfer you are asking about, and we will send you a copy of the relevant clauses and tell you which modules apply. We may redact commercial terms such as pricing and service levels; we do not redact the data protection terms, which are the part that concerns you.

How long we keep personal data

"As long as necessary" is not an answer, so here are the actual periods. Each one runs from the event in the middle column, and at the end of it we delete the data or irreversibly anonymise it.

Data that belongs to one of our customers

For personal data held inside a customer's workspace — including anything the Service captures about that customer's own personnel — the customer sets the retention period, not us. We are their processor for it. The defaults and the limits of what they can configure are described in the product annex to this policy.

We delete that data when the customer instructs us to, or at the end of the export window after their agreement ends, whichever comes first. If you are one of their people and you want their data about you deleted sooner, ask them — see the section on your rights, which explains how we route that.

What "delete" means here

Deletion is applied to live systems straight away. Backup copies are not individually edited — doing so would defeat what a backup is for — so a deleted record persists in backups until that backup ages out on the cycle above, at most 30 days. During that window the data is not used for anything, and we do not restore a backup to bring back data someone asked us to delete; a backup is restored only to recover a whole system after a failure.

Where we can keep something useful without keeping you identifiable, we anonymise instead of deleting — aggregate usage counts, for example. Once anonymised the data is no longer personal data, and it is not possible for us to re-identify you from it.

How we protect personal data

We take the measures Article 32 GDPR requires: technical and organisational safeguards appropriate to the risk, reviewed as the risk changes. In practice that means the following.

• Encryption in transit. Traffic to and from the Service travels over TLS. HTTPS is enforced, and plain HTTP requests are redirected rather than served.
• Encryption at rest. The storage holding customer content, databases and backups is encrypted at rest, and particularly sensitive values — credentials, tokens and keys — are additionally encrypted at the application layer rather than stored in readable form.
• Access control and least privilege. Access to production systems is limited to the people whose job needs it, granted by named individual accounts rather than shared logins, protected by multi-factor authentication, scoped to the narrowest role that works, and reviewed and revoked when a role changes or someone leaves.
• Network segmentation. Databases, storage and internal services sit on segmented internal networks and are not exposed to the public internet. Administrative interfaces are not publicly reachable.
• Logging. Administrative and security-relevant events are logged, retained for the period in the retention section, and monitored so that unusual activity raises an alert rather than sitting unread.
• Backups. Data is backed up regularly, held on separate infrastructure from the live systems, and restores are tested — an untested backup is a guess, not a control.
• Vulnerability management. Dependencies are scanned, code is analysed automatically before it ships, security patches are applied on a defined schedule with a faster path for serious issues, and we operate a responsible disclosure route so that anyone who finds a problem can tell us.
• Personnel. Everyone with access is bound by written confidentiality obligations that outlast their engagement, works on a need-to-know basis, and has access removed when it is no longer needed.
• Providers. We assess a provider before we engage it, contract with it under Article 28 GDPR, and hold it to security obligations at least as strict as our own.

Our Security page sets out the detail, including which measure applies to which part of the Service, our incident response process, and the shared responsibility split between what we secure and what you secure.

What we do not claim

We do not hold a SOC 2 report and we are not certified to ISO/IEC 27001, and we do not claim either. If anything you read or are told suggests otherwise, it is wrong, and we would like to know where it came from. Where we describe a practice on this page or on the Security page, we describe something we actually do; where we adopt a framework as a reference without being audited against it, we say so plainly rather than implying a certification.

No system is perfectly secure

No service, ours included, can be made completely secure, and anyone who tells you otherwise is selling something. What we can honestly promise is that we take the measures above seriously, that we keep them under review, and that if a personal data breach affects you we will act on it: we notify the CPDP where the law requires it, within the deadline it sets, and we tell affected people directly without undue delay where the breach is likely to result in a high risk to them.

Your part matters too. Use a strong and unique password, turn on multi-factor authentication where it is offered, keep your devices patched, and do not share credentials or access tokens. If you think an account has been compromised, tell us at [email protected] immediately.

Your rights over your personal data

Where we are the controller, the GDPR gives you the rights below. They are yours to use, you do not have to explain why you are using them, and using one costs you nothing.

• Access — ask whether we hold personal data about you and, if we do, get a copy of it together with the information in this policy about how it is used. (Article 15)
• Rectification — have inaccurate data corrected and incomplete data completed. Much of this you can do yourself in your account settings, which is faster than asking us. (Article 16)
• Erasure — have data deleted where we no longer need it for the purpose we collected it for, where you withdraw the consent it rested on, or where we have processed it unlawfully. (Article 17)
• Restriction — have us pause processing while a dispute is sorted out: while we check an accuracy challenge, for example, or while we consider an objection. We keep the data but stop using it. (Article 18)
• Portability — receive the data you gave us, in a structured, commonly used, machine-readable format, and have it sent to another provider where that is technically feasible. This applies to data processed by automated means on the basis of your consent or a contract with you. (Article 20)
• Objection — object to processing we base on our legitimate interests. We then stop unless we can demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or unless we need the data for a legal claim. (Article 21(1))
• Objection to direct marketing — absolute, and there is nothing to weigh. If you tell us to stop using your data for direct marketing, including any profiling connected to it, we stop. No balancing test, no grace period, no exceptions. (Article 21(2))

You also have the right to withdraw consent where consent is what we rely on, which has its own section below, and the right to complain to a supervisory authority, which has the section after that.

Some of these rights have limits written into the law itself. Erasure does not override an obligation to keep invoices for the statutory accounting period, and portability does not extend to data we inferred or generated rather than received from you. Where we cannot do all of what you ask, we will tell you which part we cannot do and why, rather than declining as a whole.

How to make a request

Write to [email protected]. Tell us which right you are using and enough about yourself for us to find the right records — the email address on the account is usually enough. You can also write to us by post at the address at the end of this policy.

• It is free. We charge nothing for a request. If a request is manifestly unfounded or excessive, particularly because it repeats one we have already answered, the law lets us charge a reasonable fee based on our administrative cost or refuse it. If we ever do either, we will explain why and tell you how to challenge that decision.
• We answer within one month of receiving the request. Where a request is complex, or where you have made several, we may extend that by up to two further months — and if we do, we will tell you within the first month, and tell you why.
• We check who you are before we hand over personal data, because the alternative is handing your data to someone who claims to be you. We ask for the least that makes us confident, usually a reply from the email address already on the account. We ask for an identity document only where nothing lighter works, and anything you send us for verification is used for that and nothing else, then deleted.

If your data sits in a customer's workspace

This is the most important paragraph on this page for many of the people who read it.

A large part of the personal data in the Service was put there by one of our customers — your employer, the organisation whose workspace you belong to, or the operator of a site built on our platform. Where the Service captures data about how an organisation's own personnel work, that data belongs to that organisation's workspace.

For that data the customer is the controller and we are only their processor. We process it on their documented instructions and for no purpose of our own, so the law directs your request to them, not to us. Practically:

• Send your request to that organisation. They decide it, and they are the ones who have to answer you within the deadline.
• If you send it to us instead, we will not ignore it. We will forward it to the relevant customer promptly, tell you that we have done so, and assist them in answering it as our Data Processing Addendum requires.
• We will not decide the request ourselves, and we will not delete, correct or hand over data from a customer's workspace without their instruction — unless a law that applies to us requires it. That is not us being unhelpful: acting on a workspace's data without the controller's instruction is precisely what a processor is not allowed to do.

If you are not sure which of the two situations you are in, ask us at [email protected] and we will tell you, and point you to the right organisation if it is not us.

Withdrawing your consent

Where we rely on your consent for something, you can withdraw it at any time, and withdrawing is as easy as giving it. You do not have to give a reason, and we do not ask you to justify it.

Withdrawing consent stops the processing from that point onwards. It does not make what we did before unlawful — processing carried out while your consent was in force stays lawful, and withdrawal does not undo it. What it does mean is that we stop, and that we do not start again unless you tell us to.

How to withdraw, purpose by purpose

• Cookies and similar technologies — open the Cookie preferences link in the footer of any page on traduora.co, turn off the categories you no longer want, and save. The change takes effect immediately. Details are in our Cookie Policy.
• Marketing emails — use the unsubscribe link at the bottom of any message we send you, or write to [email protected] and ask us to stop. Either route works, and the unsubscribe link does not require you to sign in or find your password first.
• Optional features and integrations you switched on — turn the feature off, or disconnect the connected account, in your settings. If you cannot find the switch, ask us at [email protected] and we will turn it off for you.

If you have consented to something not listed here, write to [email protected] naming it, and we will act on it the same way.

What happens next

We stop the processing, and we remove you from the relevant list or turn the relevant feature off. We keep the minimum record needed to show that you consented and that you withdrew, because being able to evidence consent is itself a legal requirement — for how long, see the retention section.

We will not quietly move the same processing onto a different legal basis to keep it running. If some part of what you asked us to stop genuinely rests on another basis as well — an invoice we are required to keep, for example — we will tell you which part and why, rather than leaving you to discover it.

Most of what we do is not based on consent at all. It rests on performing our contract with you, on legal obligations, or on legitimate interests. Withdrawing consent therefore does not close your account or switch off the Service — it affects only the things you consented to.

Complaining to a supervisory authority

If you think we have handled your personal data badly or unlawfully, you have the right to complain to a data protection supervisory authority. That right is yours regardless of anything else in this policy.

We would like the chance to put it right first. Write to [email protected], tell us what went wrong, and we will look into it and come back to you. In most cases that is the quickest way to get the outcome you actually want. You are not required to do this, and it is not a condition of complaining — you can go straight to an authority, and you can do it at any point, including while we are still dealing with your complaint.

Our lead supervisory authority

We are established in Bulgaria, so our lead authority is the Commission for Personal Data Protection (Комисия за защита на личните данни) — the CPDP. Its website, including its complaint form and current contact details, is at https://www.cpdp.bg/.

You can also complain closer to home

Under Article 77 GDPR you may lodge your complaint with the supervisory authority in the EU or EEA country:

• where you live;
• where you work; or
• where the thing you are complaining about took place.

You do not have to use ours, and you do not need our agreement to use another one. If you complain to your local authority, it will co-operate with ours through the mechanism the GDPR sets up for exactly this situation, so nothing is lost by choosing whichever is easiest for you.

You also have the right to an effective judicial remedy — against a supervisory authority's decision, and against us directly — in the courts of the country where you live or where we are established. Complaining to an authority does not use up that right.

Automated decision-making and profiling

We do not make decisions about you that produce legal effects concerning you, or that similarly significantly affect you, based solely on automated processing. No algorithm of ours decides whether you are hired, paid, promoted, disciplined, dismissed, given credit, or charged a different price. Where a decision of that kind is made about you by an organisation using the Service, a person at that organisation makes it.

We do use automated rules to detect fraud, spam, abuse and attacks against the Service — rate limits, anomaly detection, and similar. Those rules can block a request or temporarily restrict an account. If one of them affects you, write to [email protected] and a person will review it.

Where a customer turns on AI features, be aware of this

This is the part worth reading carefully, because it is easy to misunderstand.

Some of our products capture activity data on behalf of a customer — an employer, typically — and some of them offer optional AI features on top of it. Where a customer enables those features, the Service can generate automated assessments of the activity it captures. The clearest example: classifying whether the content of a captured screen appears to be work-related. Other examples include scoring or summarising captured activity and grouping it into categories.

Four things follow, and we would rather state them plainly than let them be discovered later.

• The output goes to the customer, not to us. It is presented to the organisation whose workspace the data belongs to. That organisation is the controller of it, and we are only its processor.
• The customer decides what, if anything, to do with it. We do not act on these assessments, we do not use them for any purpose of our own, and we do not share them with anyone else.
• These outputs are not decisions, and must not be used as if they were. An automated assessment is an input to a human judgement. Our terms require the customer not to treat an output of the Service as an automated decision about a person, and to apply meaningful human review before acting on one. Whether any particular use is lawful where that customer operates — including the lawful basis for it, the notices it has to give, any impact assessment it has to carry out, and any consultation with employee representatives it has to run — is that customer's responsibility to determine, not ours.
• They can be wrong. A classifier reading a screen has no idea what your job is. It can label genuine work as unrelated, and it can miss the opposite. Anyone relying on one of these outputs should treat it as a rough signal, and we say so to our customers as well as to you.

If an assessment about you has been generated

Ask the organisation whose workspace holds the data — normally your employer. You can ask them for human involvement, for an explanation of how the assessment was reached, to express your point of view, and to contest the result. They are the controller, so they are the ones who have to answer.

If you send that request to us, we will forward it to them promptly, tell you we have done so, and assist them in answering it. See the routing paragraph in the section on your rights, which explains why we cannot decide it ourselves.

Children

The Service is not directed at children, and we do not knowingly collect personal data from them. It is a business product, bought by organisations and used by the people who work in them. We do not design it for children, we do not market it to them, and we do not offer accounts to them.

Where consent is the basis for an online service offered directly to a child, the GDPR sets the age at which the child can consent alone. In Bulgaria that age is 14. Other EU and EEA countries set it anywhere between 13 and 16, and the age in the country where the child lives is the one that applies. Below that age, consent has to come from — or be authorised by — a holder of parental responsibility. Because we do not offer the Service to children, we do not operate a parental consent mechanism, and a child under the applicable age should not create an account or submit personal data to us.

If a child's data has reached us

Tell us. Write to [email protected] with enough detail for us to find the record — an email address, an account name, or the page where the data was submitted. You do not need to prove anything first, and you do not need to be the child's parent to report it.

We will check, and where we confirm that we hold personal data collected from a child without proper authorisation, we will delete it without undue delay, keeping only what a law that applies to us requires us to keep.

If the data sits inside one of our customers' workspaces rather than in our own records, the customer is the controller of it. Tell them as well, and tell us — we will forward your report to them and press for it to be dealt with, as the routing paragraph in the section on your rights describes.

Links and content from other sites

Our websites and the Service link to services we do not run, and some pages embed content that other people host — videos, maps, code repositories, documentation and similar.

Following a link takes you somewhere this policy does not reach. Loading embedded content means the provider hosting it receives data directly from your browser, typically your IP address, your device and browser details, and the page you were on, and it may set its own cookies.

We do not control those services, and this policy does not apply to them. What they collect and what they do with it is governed by their own privacy notice, which is the one to read before you use them. Where embedded content is not strictly necessary to deliver a page, we load it only once you have agreed to the relevant cookie category — see our Cookie Policy.

A link is not an endorsement. If a link from our site takes you somewhere that mishandles your data, we would like to know at [email protected] so we can reconsider carrying it.

Changes to this policy

This policy changes when the Service changes, when we engage or replace a provider, or when the law moves. We would rather update it than let it drift out of date and quietly stop being true.

Every version carries a version number and the date it takes effect, shown at the top of the page. This is version 1.0.2, in force from 2026-08-02.

How we tell you

• Minor changes — clarifying wording, correcting a mistake, adding a provider of a kind already described — are published with a new version number and a new effective date. We do not send a separate notice for these.
• Material changes — a new purpose, a new category of personal data, a new category of recipient, a longer retention period, a change to how you exercise your rights, or a change to the legal basis we rely on — are notified at least 30 days before they take effect, by email to account holders and by a notice on the site. That gives you time to read them and to act before they apply.
• Changes that need your consent are not made by publishing a new version. We ask you, and we treat silence as a no.

This policy is a notice, not a contract. We do not ask you to accept it, and continuing to use the Service is not us collecting your agreement to it. Where we genuinely need your agreement to something, we ask for it separately and record it.

Previous versions stay available

We do not overwrite the past. Every version of this policy that we have published remains available, with the dates it was in force, from the version history linked at the foot of https://traduora.co/privacy. If you want to know what we said about your data on a particular date, that is where to look — and if you cannot find it, ask us at [email protected] and we will send it to you.

How to contact us

The controller for the personal data described in this policy is Ever Technologies LTD, registered in Bulgaria under company number 204599535, with its registered office at Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria.

• Privacy questions, and any request about your personal data — [email protected]
• Data protection correspondence — [email protected]

Both addresses are monitored by the same people, and either will reach us. By post, write to the registered office above and mark the letter for the attention of the privacy team. We correspond in English.

We have not designated a Data Protection Officer under Article 37 GDPR. The [email protected] address is a contact channel, not a designation, and we will not describe it as one. If that position changes, this policy will say so and will give the designated office's contact details.

If your question is about personal data held inside one of our customers' workspaces, that customer is the controller and the request goes to them — see the routing paragraph in the section on your rights. Write to us anyway if you are unsure, and we will tell you who to ask.

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