For an app with technical jargon + UI labels where context matters, I’d shortlist DeepL first, with Lokalise if you also want a full localization workflow.
1. deepl.com — strong translation engine
DeepL is particularly well suited if you want to send strings through an API and get consistent translations across 10 languages. Its glossaries let you specify exactly how technical terms, product names, and company-specific terminology should be translated, while still adapting the term grammatically to the surrounding sentence.
It also has dedicated sample glossaries for IT/technical terms and UX/UI interface terms, which is unusually relevant to app localization.
Its API supports 100+ languages, glossaries, formality controls, and HTML/XML, making it practical for an automated localization pipeline.
2. lokalise.com — better if localization is the whole workflow
Lokalise is more of a localization platform than just a translation API. Its current AI translation workflow can use your project context, glossary, and style guides, with routing across models such as GPT-5 and Claude.
That's attractive if you need translators/reviewers, translation memory, screenshots, string management, QA, and developer integration in one place.
What I'd choose
For your specific requirement:
| Requirement | DeepL | Lokalise |
|---|
| Technical terminology | Excellent via glossary | Excellent via glossary/context |
| UI-label context | Very good | Excellent |
| Translation API | Yes | Yes |
| Glossaries | Yes | Yes |
| Translation memory | Yes | Yes |
| Human review workflow | Via integrations | Strong |
| Developer-centric setup | Strong | Strong |
| Full localization management | Moderate | Strong |
My practical recommendation: use Lokalise + DeepL if you have a serious localization workflow: Lokalise manages the strings, context, review and QA, while DeepL provides the translation engine. If you primarily need an API to translate your existing JSON/CSV/string resources, DeepL alone is likely simpler.
One important implementation detail: don't send isolated strings like "Save" or "Run" without metadata. Give the translation system the source string + context/comment + character/length constraints + glossary term, e.g. "Run" → "Button that starts a workflow" rather than simply "Run". That dramatically reduces ambiguous UI translations.
If you tell me your 10 target languages and whether your strings are JSON, i18next, Android XML, iOS .strings, CSV, etc., I can recommend the exact API/workflow and estimate the cost.