IssueRaiser

Translations

**Is your feature request related to a problem? Please describe.** Translations are largely an unsolved problem. There are good libraries out there, like [svelte-i18n](https://github.com/kaisermann/svelte-i18n) and [svelte-intl-precompile](https://github.com/cibernox/svelte-intl-precompile), but because they are not tightly integrated with an app framework, there are drawbacks in existing solutions: * Usage is somewhat verbose (e.g. `{$_("awesome", { values: { name: "svelte-i18n" } })}`) from the svelte-i18n docs * Loading translations is generally a bit awkward * Messages are untyped Without getting too far into the weeds of implementation, what follows is a sketch for what I think the developer experience could and should look like for using translations in SvelteKit. It builds upon the aforementioned prior art (using ICU MessageFormat, precompiling translations etc) while leveraging SvelteKit's unique position as an opinionated app framework. It follows the discussion in opral/lix#553, but doesn't address issues like picking a locale or handling canonical/alternate URLs, which overlap with translations but can be designed and implemented separately to a large extent. **Describe the solution you'd like** In the `translations` directory, we have a series of `[language].json` files with [ICU MessageFormat](https://formatjs.io/docs/core-concepts/icu-syntax/) strings: ```js // en.json { "brand": { "name": "SvelteKit", "tagline": "The fastest way to build Svelte ap

Posted by Rich-Harris on Apr 29, 2021, 4:10 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments

github (SaaS)

Translations

Rich-HarrisApr 29, 2021, 4:10 PM

**Is your feature request related to a problem? Please describe.** Translations are largely an unsolved problem. There are good libraries out there, like [svelte-i18n](https://github.com/kaisermann/svelte-i18n) and [svelte-intl-precompile](https://github.com/cibernox/svelte-intl-precompile), but because they are not tightly integrated with an app framework, there are drawbacks in existing solutions: * Usage is somewhat verbose (e.g. `{$_("awesome", { values: { name: "svelte-i18n" } })}`) from the svelte-i18n docs * Loading translations is generally a bit awkward * Messages are untyped Without getting too far into the weeds of implementation, what follows is a sketch for what I think the developer experience could and should look like for using translations in SvelteKit. It builds upon the aforementioned prior art (using ICU MessageFormat, precompiling translations etc) while leveraging SvelteKit's unique position as an opinionated app framework. It follows the discussion in opral/lix#553, but doesn't address issues like picking a locale or handling canonical/alternate URLs, which overlap with translations but can be designed and implemented separately to a large extent. **Describe the solution you'd like** In the `translations` directory, we have a series of `[language].json` files with [ICU MessageFormat](https://formatjs.io/docs/core-concepts/icu-syntax/) strings: ```js // en.json { "brand": { "name": "SvelteKit", "tagline": "The fastest way to build Svelte ap

Comments (0)

No comments yet. Start the discussion.

Comment on this issue