add namespaces functionality

[ivanhofer]

Namespaces would be a native option to load only selected parts of the translations. Useful for bigger applications so not all messages need to load the same time e.g. translation that are only needed in the settings panel are not needed on the login page.

You would define your translations something like:

// index.ts
import type { Translation } from '../i18n-types'
import { workspace } from 'typesafe-i18n'

const en: Translation = {
   login: workspace('login')
   settings: workspace('settings')
   dashboard: {
      // ...
   }
}

export default en

// login.ts
import type { LoginTranslation } from '../i18n-types'

const login: LoginTranslation = {
   label_password: 'Password:',
   label_username: 'Username:',
   // ...
}

export default login

// settings.ts
import type { SettingsTranslation } from '../i18n-types'

const settings: SettingsTranslation = {
   email: 'Email preferences:',
   // ...
}

export default settings

where workspace would be a function that loads the workspace via an async import

const loadedWorkspaces = { }

export const workspace = async (workspaceToLoad: string) => {
  const ws = loadedWorkspaces[workspaceToLoad]
   if (ws) return ws

   loadWorkspace(workspaceToLoad)

   return { } // a dummy-workspace
}

export const loadWorkspace = async (workspaceToLoad: string) => {
   loadedWorkspaces[workspaceToLoad] = (await import(`./${workspaceToLoad}`)).default
}

Because workspaces would be loaded asynchronously, we would make sure that calling LL.login.label_password() would return the translated value: How can we do that?

• call somewhere a loadWorkspace('login') function
  the function would need to get called before the actual translation call
• show an empty string until the data finishes loading in background
  since the whole translation object is reactive, we can initialize the loading and as soon as the translations are back, we can update the object that holds all workspaces

A developer then can decide if he manually loads the correct workspace somewhere in the code (e.g. triggered by a certain route) or the user should see blanks until translations are loaded. Also a method to check if a workspace is currently loading will be exposed so a loading spinner can be shown.

It should be possible to nest workspaces as often an user wants.

What needs to be done:

• create custom types that only include part of the workspace translations
• make sure all translations define the part of the subtree as a workspace
• implement reactivity for loading workspaces asynchronously
• function to check if workspace is currently loading

[mullwaden]

Kind of related feature that might be interesting. In a very large project, having all of the copy in one place becomes challenging. Right now (I could be wrong) the setup forces a structure like:

src/notifications/published.ts
src/i18n/translations/en/published_copy.ts
src/i18n/translations/de/published_copy.ts

whereas something like this, allowing the copy to be colocated with the component/function could be very helpful to avoid jumping around in the codebase:

src/notifications/published.ts
src/notifications/published_copy.ts  (perhaps with sub-exports like   export const en = { } )

[ivanhofer]

I'm not sure if I got it correct.

You can do that already, but you would need to import these objects inside the src/i18n/[locale]/index.ts file.
To simplify the generator, it uses the index.ts file's default export as the entry point to all your locales. What you then do inside that file is up to you. You can import anything that lays inside the root of your project.

You can have a file src/notifications/published.ts that exports part of a dictionary in multiple languages like

export const notifications_en = {
  prop1: 'This is a test'
}

export const notifications_de = {
  prop1: 'Das ist ein test'
}

and then reference it inside src/i18n/en/index.ts like

import { notifications_en } from 'src/notifications/published.ts'

const en: BaseTranslation = {
   ...notifications_en
}
export default en

and inside src/i18n/de/index.ts like

import { notifications_de } from 'src/notifications/published.ts'

const de: Translation = {
   ...notifications_de
}
export default de

Is this what you want?

[ivanhofer]

@mullwaden did you see my comment above?

[mullwaden]

yes! I ended up putting everything in the translations folder though. It works better with the automatic updates of the types.

One idea would be to go the route that jest, storybook and less go, where they automatically pick up files, e.g.
myClass.ts
myClass.test.ts

Imagine then you could do something like

import translation from "./myClass.translation";

const title = translation.en.title();

It can be done, but it would require some interesting webpack shenanigans... In fact you could probably at that point entirely hide the types file and make it part of the regular build process.

[ivanhofer]

@mullwaden sounds interesting. Pleas open a discussion with some more details. Maybe it is a topic for the future.

[EstebanBorai]

@mullwaden I'm interested in this thread, is the discussion available somewhere? Thanks in advance!

[ivanhofer]

@mullwaden @EstebanBorai namespaces are here!! 🎉
I just released version 4.0.0
Here is the namesapces-section of the docs. Please share your feedback!

[ivanhofer]

@EstebanBorai did the updgrade went well? :)

[EstebanBorai]

@ivanhofer thanks for being tuned I really appreciate that!
I haven't tried the new version already as I have tasks in progress right now, but I have this listed in my top priorities, I will let you know if I find any issues!

[ivanhofer]

Sure, just take your time :)

[bitdom8]

Really great namespace functionality. Maybe would be better instead of {$LL.login.Login()}

{$LL.Login()}

Don't want to track separates folders for translations

[ivanhofer]

@bitdom8 In my opinion having namspaces without a nesting structure makes it hard to understand that you need to load a namespace in order to render that specific message.
Having all namespaces in it's own file is an easy way to load just the files you want to use without relying on compile time optimizations.

In the end typesafe-i18n is plain old JavaScript ant it is as flexible as the programming language allows. So you can also do something like this if you want to avoid the nesting structure in your template:

<script>
   $: T = $LL.login
</script>

<button>{T.Login()}</button>

If this doesn't fit your needs, you can always use the raw i18nObject function and create your own namespacing and translation loading logic on top of typeasfe-i18n.

[bitdom8]

Yea, I thought that then making it global is better somehow. But as you told, keeping it more structured make it more useful. Спасибо @ivanhofer

[bitdom8]

There is a simple slug problem with - and — on namespace: why-us.svelte is not addable to namespace.

const why-us_login: BaseTranslation = {
    Why_us: "Neden biz",
 }

errs:

Cannot find name 'us_login'

There is also a page with path:

src\routes[lang]\analysis[title].svelte

import type { BaseTranslation } from '../../i18n-types'

const en_analysis_[title]: BaseTranslation = {
'Draft sentences': 'Draft sentences',
}

Not works as en_analysis_[title]. How should we proceed please? Need help @ivanhofer

const loadNamespaceAsync = async (locale, namespace) => void updateDictionary(locale, { [namespace]: (await localeNamespaceLoaders[locale][namespace]()).default });

const loadNamespaceAsync = async (locale, namespace) => void updateDictionary(locale, { [namespace]: (await localeNamespaceLoaders[locale]namespace).default });

                                                             ^

TypeError: localeNamespaceLoaders[locale][namespace] is not a function

[ivanhofer]

It looks like you are not using valid JavaScript syntax for your varaible names.
As far as I know you only can use a-Z, 0-9 and _ and $ inside the name of a variable.

[bitdom8]

Thanks @ivanhofer . Understood now. en_analysis_[title] can't be used, but we can use any namespace independent from pathnames

[ivanhofer]

the only restriction is that you need to create a file called index.ts that exports a default export containing your translations