I am the author of this Dual Sub Chrome Extension: https://chromewebstore.google.com/detail/learn-finnish-dual-subtit/olmapcjpickcoabnjleheppoignffpdd .
Here is landing page: https://finnish-streaming-dual-sub.netlify.app/ and demo video: https://www.youtube.com/watch?v=O3B7BCvd99Y
It is an open-source project, translates Finnish subtitle to other languages. Users need to register to DeepL system and get DeepL token / translation key. By this way, motivated users can get their own key and the project can live well without active maintenance from my side. Now my app gets more than 250 installations without marketting.
I'd like to raise one concern regarding the recent pricing changes. The Free and Pro tiers have been replaced by Developer and Growth, with Growth costing €29.75/month for 1 million characters. For individual language learners, 150,000 characters per month is typically more than enough — making the Growth tier feel disproportionately expensive.
Would it be possible to introduce a more accessible B2C tier? Something like a €5 base price with pay-as-you-go for extra usage would make a real difference. It would also help greatly if users could purchase translation keys via Google Pay, Apple Pay, or PayPal — credit card requirements can feel intimidating for individual users and create unnecessary friction.
I am the author of this Dual Sub Chrome Extension: https://chromewebstore.google.com/detail/learn-finnish-dual-subtit/olmapcjpickcoabnjleheppoignffpdd .
Here is landing page: https://finnish-streaming-dual-sub.netlify.app/ and demo video: https://www.youtube.com/watch?v=O3B7BCvd99Y
It is an open-source project, translates Finnish subtitle to other languages. Users need to register to DeepL system and get DeepL token / translation key. By this way, motivated users can get their own key and the project can live well without active maintenance from my side. Now my app gets more than 250 installations without marketting.
I'd like to raise one concern regarding the recent pricing changes. The Free and Pro tiers have been replaced by Developer and Growth, with Growth costing €29.75/month for 1 million characters. For individual language learners, 150,000 characters per month is typically more than enough — making the Growth tier feel disproportionately expensive.
Would it be possible to introduce a more accessible B2C tier? Something like a €5 base price with pay-as-you-go for extra usage would make a real difference. It would also help greatly if users could purchase translation keys via Google Pay, Apple Pay, or PayPal — credit card requirements can feel intimidating for individual users and create unnecessary friction.
If you enable the translation history feature in the macOS app, it starts to lag significantly after just a couple of weeks. You end up waiting 5 seconds just to see your cursor again—until you clear the history completely.
Either this needs to be fixed, or the settings should allow you to limit the history to a certain period of time
Hey everyone 👋 quick recap of what’s been happening this week across DeepL Bridges:
🎤 Upcoming: Deep Dive into the DeepL Voice API
Our next DevTalk is coming up on May 12th, 5–6pm Berlin time with Christian Meißner Technical Lead for the DeepL Voice API.
We’ll focus on real-world implementation: how to use the Voice API in projects, real-time translation workflows, architecture decisions, SDK usage, and practical questions.
👉 If you’re building with the Voice API, exploring what’s possible, or just curious, feel free to drop questions in advance.
🛠️ Made with DeepL: VoiceBuddy
Tim shared VoiceBuddy, an open-source Windows app that provides real-time translated captions for any audio playing on your system: YouTube, Twitch, Discord, game voice chat, Zoom, podcasts, and more.
It’s a great example of what can be built with the newly released DeepL Voice API.
👉 Check it out, test it, and share feedback or questions in the thread.
💻 DeepL API Prompts: feedback wanted
Tim also shared a new GitHub repository with sample prompts, schemas, and examples for using the DeepL API with coding agents.
Since this approach is still fairly new, feedback would be very helpful, especially from anyone already using AI-assisted development tools.
💬 Ongoing API & product discussions
There’s still ongoing discussion around the Style Rules endpoint, where the API team is gathering feedback on endpoint structure, language-specific handling, formatting preferences, and developer workflows.
👀 Looking ahead
DevTalk: Deep Dive into the DeepL Voice API → May 12
More builder-focused discussions and project showcases coming soon
Keep sharing what you’re building, testing, or experimenting with!
Hey there!
A while ago we created a new repository on GitHub with a somewhat different approach.
The repository hosts only samples, schemas and example prompts.
Theese prompts are supposed to help you get started with the DeepL API in your favorite Coding Agent. As this is still relatively new I would love a few more eyes on this to give us feedback.
Particularly curious about if you'd consider this approach actually helpful or not 🙂
https://github.com/DeepLcom/deepl-api-prompts
Hey everyone 👋 quick recap of what’s been happening this week across DeepL Bridges:
🎤 Upcoming: Deep Dive into the DeepL Voice API (AMA)
Our next DevTalk is coming up! Now scheduled for May 12th, 5–6pm (Berlin time) with Christian Meißner (Technical Lead, Voice API).
We’ll focus on real-world implementation:
How to actually use the Voice API in projects
Architecture decisions and trade-offs
Real-time translation workflows
👉 If you haven’t yet, feel free to drop questions in advance, this helps make the session more relevant for everyone.
🛠️ Recent sessions: building and showcasing
Over the past weeks, we’ve hosted hands-on formats:
“Let’s Build! – DeepL Voice”
→ live prototyping session exploring what can be built with the Voice API in a relaxed, collaborative format
Show & Tell – TranslateSheet
→ first community showcase with real project insights (recordings now available)
These sessions are a great starting point if you’re thinking about building something yourself.
💬 Product & API discussions
There’s still ongoing discussion around the Style Rules endpoint, where the API team is actively gathering feedback.
We’ve already seen:
concrete suggestions on API structure and endpoint design
discussion around language-specific handling and developer workflows
👉 If you’re working with the API, your input here can directly shape what gets built.
🐛 Community feedback & issues
We’ve also seen a few smaller issues and usability topics come up (e.g. session handling / UI quirks).
These are being picked up and forwarded internally. Keep them coming, they’re valuable signals for the team.
👀 Looking ahead
DevTalk (Voice API AMA) → May 12
More hands-on and builder-focused formats coming up! Stay tuned.
I often get the Popup that my Session expired.
After I click "Weiter" it just logs me in again. This usually happens when I use DeepL on another PC/Browser and then go back.
Then I'm logged in again.
Tim Cadenbach told me to post it here - so Imma just mention you here.
Specs: Browser is usually Brave, OS doesn't matter (Win11 and macOS)
Another note: While creating this post and selecting tags, the select menu clips out 😅 (this is at the bottom of my screen)
We’re hosting another DevTalk this week, and this one goes deep!
This Thursday, April 23, 5-6pm (Berlin time) May 12th 2026, 5-6pm join us for a live AMA with Christian Meißner, the Technical Lead behind the DeepL Voice API.
(call was moved to a new date unfortunately)
This session is focused on real-world implementation:
How to actually use the Voice API in your projects
Architecture decisions and trade-offs
Real-time translation workflows
Lessons learned from building with the API
Whether you’re already building with the API or just exploring what’s possible, this is your chance to go straight to the source.
We’ll keep it highly technical, bring your questions, your ideas, or even your code. Feel free to ask any questions in advance in this thread!
🗓 Date: May 12th 2026 5-6pm
🎤 Format: Live AMA
👨💻 Audience: Developers & technical builders
Ask anything. Bring code.
>> Event Link
Hey everyone,
2 weeks ago we had our very first community Show & Tell session with Christopher Daniel Dean about his TranslateSheet project. Took a while but here's some of the videos!
TranslateSheet in Figma
And TranslateSheet in Google Sheets plus Image Localization
Stay tuned for our next sessions and always have a look at our Events section
Working on something cool you want to talk about? Let us know! Feel free to add your work into our Made With DeepL area!
Hey everyone! I'm a PM on the API team at DeepL, coming to you with the chance to help shape a new DeepL API 🙂
Background
Style rules let you define language-specific formatting and writing preferences (date formats, units of measure, active vs. passive voice, etc.) that get applied to your translations. With our recent release, you can now create and manage them via the API.
The available rules you can configure when creating a style rule depend on the target language. For example, a rule called writing_dates might exist for Italian, but be called date_format in French.
Right now there's no programmatic way to discover which rules are available for a given language before creating a style rule. We're designing a new endpoint to solve this (similar in spirit to the v3/languages beta that Mike shared recently), and I'd love your feedback on a couple of design decisions before we build it.
What we're planning
A new endpoint that lets you query available style rules per language. Something like:
GET /v3/style_rules/available_rules?language=fr
The response would include each rule's description (in English and the target language), available options, and examples where applicable. Here's an abridged sample for Spanish:
{ "language": "es", "configured_rules": { "numbers": { "spelling_out_units": { "description": { "en": "When writing units of measure", "local": "Al escribir unidades de medida:" }, "options": { "always_spell_out_units_of_measure": { "description": { "en": "Always spell out, with or without a numeral", "local": "Escribir siempre con letras" }, "example": "Example: 4 kilos; algunos kilos" }, "always_abbreviate_units_of_measure": { "description": { "en": "Always abbreviate, with or without a numeral", "local": "Usar siempre los símbolos" }, "example": "Examples: 4 kg; algunos kg" } } } } }
}
Some rules only have a single option (like "use active voice"), in which case the rule and option descriptions are the same. Not all rules have examples.
Where I'd love your feedback
Dedicated endpoint vs. extending v3/languages.
Does a separate endpoint make sense to you, or would you prefer a single place to get all language capability info?
We considered adding this data to the existing v3/languages endpoint, which already tells you whether a language supports style rules.
However, the rule catalog per language is significantly more verbose than any other product's data in that endpoint, and we think a dedicated endpoint gives us more flexibility to design the right response shape.
Response body shape:
Looking at the sample above, does the structure make sense for how you'd use it? Is there anything missing, or anything you'd change?
For context, our goal is to give you everything you need to build a UI or programmatic integration on top of style rules without hardcoding language-specific logic.
This endpoint doesn't exist yet, so now is the perfect time to shape it. Would love to hear from anyone who's working with style rules or planning to.
Thanks for reading!
Hi all, my name is Mike, and I'm a product manager working on the DeepL API 👋
A couple of weeks ago, we released v3/languages endpoints in public beta. You can learn more and try it out here: https://developers.deepl.com/api-reference/languages/retrieve-supported-languages-by-product
We're aiming to address challenges and shortcomings users have raised about v2/languages (and v2/glossary-language pairs), and while we believe the beta makes good progress, we'd like to hear more user feedback before we finalize the API design and move into GA.
We're eager to hear from users of v2/languages on the direction we've taken with v3/languages along with any and all of the pain points you've come across when using v2.
Thanks for being part of this community, and we hope to hear from you!
