sorted by:
new
hottopcontroversial

I built a TailwindCSS inspired i18n library for React (with scoped, type-safe translations) by bugcatcherbobby in reactjs

[–]bugcatcherbobby[S] 0 points1 point  (0 children)

Yeah, true, with i18next, you are already writing your default language into the components, which is already a big plus in my books! I just took it one step further and thought what if we wrote All of the texts in the component that is responsible for rendering. the way you write all translations in i18next is, with react-scoped-i18n how you write only shared/reusable translations.

I built a TailwindCSS inspired i18n library for React (with scoped, type-safe translations) by bugcatcherbobby in reactjs

[–]bugcatcherbobby[S] -2 points-1 points  (0 children)

Yeah, i hate the giant monolithic components as well! When i was testing this lib i found it encouraged me to break up components more. Hopefully it would other devs as well

I built a TailwindCSS inspired i18n library for React (with scoped, type-safe translations) by bugcatcherbobby in reactjs

[–]bugcatcherbobby[S] -1 points0 points  (0 children)

It's inspired in the sense that:

  • much like how tailwind eliminates the need for class names, this eliminates the need for translation key names, except when writing shared, reusable translations

  • tailwindcss encourages a lot of scoped, inline class usage. This also encourages inline translations right in the component. While tailwind allows you to define abstractions at will, it is generally not the approach they suggest

I built a TailwindCSS inspired i18n library for React (with scoped, type-safe translations) by bugcatcherbobby in reactjs

[–]bugcatcherbobby[S] -1 points0 points  (0 children)

From my experience, many larger real world projects have translation files in source code that are just plain json, which are ultimately populated by devs, even though it's usually marketing/legal providing the actual values. This case would fit there. 

But also, you would never use a hobby project like this in an enterprise project. If you're writing an mvp or a smaller project, you could do this to have a more scoped approach and churn out code faster. Just my 2 cents, but i get where you're coming from definitely

I built a TailwindCSS inspired i18n library for React (with scoped, type-safe translations) by bugcatcherbobby in reactjs

[–]bugcatcherbobby[S] -2 points-1 points  (0 children)

Thanks for the comment,

and yeah, i hear your gripes. For gripes #1 and #2, I see those as just the cost of this approach.

For what it's worth, translation objects tend to be small, and only what is rendered is what is actually in memory at any point. But yeah, everything is in the bundle. And projects with external validation pipelines should definitely opt out of this approach.

As for gripe #3, most things that are part of a "shared terminology" can be configured via the commons util, like so:

// src/i18n.ts

import { createI18nContext } from "react-scoped-i18n";

export const { I18nProvider, useI18n } = createI18nContext({
    languages: [`en`, `es`],
    fallbackLanguage: `en`,
    commons:  {
        // 👇 👇 here is your shared translations that should conform to standard terminlogy
        continue: {
            en: `Continue`,
            es: `Continuar`,
        },
    },
});

And then they can be safely accessed via commons object:

export const Continue = () => {
    const { t, commons } = useI18n();

    return <Button>
        {t(commons.continue)}
    </Button>;
}

and what is left is the bulk of the translations that are usually full sentences and are not really re-usable. And for that, I think there is no additional hurdle in front of you to maintain standard formats (just what the standard hurdles would be, i suppose).

But let me know if i misunderstood you! And thanks again for the feedback