Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
IDs vs base language string as ID is a common debate. I opted for translation IDs since Mozilla's Fluent (https://projectfluent.org/) uses translation IDs. I can't find their list of reasons. I do remember having problems myself by changing the base language string and thereby losing the connection to all translations.
The argument against IDs is the reduced readability. Something that can be solved with the IDE extension.
Is there something else that bothers you in localization pipelines?
Since months I am working on an open source localization solution that tackles both developer and translator facing problems. Treating translations as code completely leaves out translators, who in most cases can not code.
I am working on making localization effortless via dev tools and a dedicated editor for translators. Both pillars have one common denominator: translations as data in source code. Treating translations as code would break that denominator and prevent a coherent end-to-end solution.
Take a look at the repository https://github.com/inlang/inlang. The IDE extension already solves type safety, inline annotations, and (partially) extraction of hardcoded strings.
Related posts
- Internationalize TypeScript app
- FTL loader
- Requesting feedback on a string interpolation concept
- Questions about a translation system
- l10n: A proc macros crate to ease project localization and provide compile time checks (message exists, mandatory arguments are set, functions are defined) built upon fluent-bundle.