pain: integrate i18n into existing code base

[samuelstroschein]

Problem

Including i18n in an existing project most likely requires wrapping all text in some sort of t function.

[ivanhofer]

I don't think wrapping translations into a t function is the pain-point of i18n. It is more the error-proneness of the translation-process itself:

• do I still have some hard-coded strings?
• is a text missing in my translations?
• did I miss to add a variable to a translation?
• did I forget to call the translation with an argument?
• did I passed a number instead of a Date as argument?
• I have changed my base translation, but did I update it everywhere in my codebase?
• how to be sure my application works in all my 10+ languages? I certainly don't want to test every locale manually when I commit something
• configuration: I don't want to update 5 files if I add a new locale
• IDE support: code-completion, inline-hints

Additional topics that concern me:

• how do I detect the correct language of my users?
• lightweight: I don't want to add a 40+kb library to my 5kb application to support two languages
• easy plural support
• only load the locale a user currently sees
• locale-dependent formatting of date and time information
• syntax: I really find it hard to read the ICU syntax even for simple examples:
  Updated: {minutes, plural, =0 {just now} =1 {one minute ago} other {{{minutes}} minutes ago by {gender, select, male {male} female {female} other {other}}}}
• I want the same i18n experience everywhere. I want to use the same syntax/configuration for my Node.JS backend, my private Svelte projects and the react-applications I write at work

For the reasons above, I have created typesafe-i18n which improves the developer-experience a lot.
But it's far from perfect. There still exist some pain-points, you seem to address with your project. Let me know if I can help :)

[samuelstroschein]

First of all, thanks for the in-depth replies to all open discussions and this valuable input! :)

There still exist some pain-points, you seem to address with your project.

Which pain-points did you have in mind? The points you listed seem to be mostly solved with your (highly acclaimed) typesafe-i18n package.

---

Regarding typesafe-i18n, I read your comment on Reddit asking how to improve the experience: The readme is overwhelming. After 10 minutes of searching for clear instructions on how to integrate typesafe-i18n in a simple svelte project, I moved on. Splitting the readme in smaller chunks seems appropriate, or have a getting started with X: React | Svelte | Vue at the start of the readme would help.

[ivanhofer]

Pain-points are:

• syncing the code and translations: my plan for typesafe-i18n is described here. In an ideal world, the translations are fetched via a npm-command and the locale-files are being generated.. If something is wrong in the translations, TypeScript will inform you and you are not able to build the application. Maybe also webhooks exist, that trigger this process when a translation is updated and rebuilds the application for instant feedback.
• when using a translation-service, it cannot be guaranteed that e.g. variables are missing in the translations, because these services are basically just a simple text-field without validation. A i18n-syntax-aware service is needed (and also a check against the base translation)
• making sure that no string is hard-coded and forgotten to translated. I have a partially answer to that problem, but it cannot be automated and requires development effort to extend components with this strict type-checking.

From technical side:

• the final bundle should contain optimized translations so the client doesn't have to do a lot of work. See here.

---

I'm always trying to improve the documentation. It is a long document, but you always can CMD+F to search for the text you need. There exists an Usage-section that lists all available integrations. Each integrations links to a sub-directory which contains an example. You can find the svelte-version here. There is also a small documentation on how to set it up in a svelte project.
(I just saw that I need to update it, because SvelteKit now uses vite instead of the older rollup-approach. This would mean to use the node-process to run the generator).

Please let me know what is unclear to you and what I can do to improve the README?

[samuelstroschein]

syncing the code and translations: my plan for typesafe-i18n is described here. In an ideal world, the translations are fetched via a npm-command and the locale-files are being generated.. If something is wrong in the translations, TypeScript will inform you and you are not able to build the application. Maybe also webhooks exist, that trigger this process when a translation is updated and rebuilds the application for instant feedback.

Kinda steering in the same direction of our current prototype. Instead of fetching the translations, the translations are committed as js file to the repo (which could be changed to ts #13 to get type safety).

A i18n-syntax-aware service is needed (and also a check against the base translation)

Your critique is that current i18n services are just exporting a "dumb" json file that is not checked/verified during development?

Please let me know what is unclear to you and what I can do to improve the README?

I took a look at the sveltekit example, it's actually pretty easy. I assume I will try it out this or next week again.

[ivanhofer]

@samuelstroschein I think we both want the i18n experience to improve. Maybe we can join forces and build something together.
typesafe-i18n could be the i18n library for an application and the service you currently intend to build could be the translation service on top of typesafe-i18n?
Maybe we can align a meeting and discuss a possible solution? You can contact me on twitter if you want.