Avoid duplication of loader function

[Hydhen]

Hello!

I am working on a project that offers various features designed to be as independent as possible. This involves organizing translations for each feature into separate translation files.

The structure of my components is outlined below:

+- features/
|-+- article/
| |-+- components/
| | `- ...
| |
| |-+- i18n/
| | |- fr.json
| | `- en.json
| |
| |- article.html
| |- article.scss
| `- article.ts
|
`-+- bookmark/
  |-+- i18n/
  | |- fr.json
  | `- en.json
  |
  |- bookmark.html
  |- bookmark.scss
  `- bookmark.ts

Currently, I have a provider set up for each feature like this:

const loader = (availableLanguages: string[]) => {
    return availableLanguages.reduce((acc, lang) => {
        acc[lang] = () => import(`./i18n/${lang}.json`);
        return acc;
    }, {});
};

@Component({
    providers: [provideTranslocoScope({ scope: 'scope', loader })]
})
export class Component {}

To streamline the code across multiple features and components, I aim to centralize the loader function app-wide. Thus, I've devised the following generic approach:

export const loader = (availableLanguages: string[], path: string) => {
    return availableLanguages.reduce((acc, lang) => {
        acc[lang] = () => import(`${path}/i18n/${lang}.json`);
        return acc;
    }, {});
};

However, I'm facing an issue with providing the correct path to this shared loader function so that it can load scoped translation files appropriately. Unfortunately, accessing __filename or __dirname isn't feasible in my scenario – both during development and in the built project.

If you have any insights on how to address this challenge effectively, your input would be greatly appreciated.

Possible related discussion: #571

[shaharkazaz]

@Hydhen Here is a simple implementation of a reusable concept.
BTW in your example, why is the loader a function accepting the available langs?

[Hydhen]

We're building a product that can use different set of languages based on client needs, some might need [en, fr], while others need [en, de, ru]

I think your example won't work in my case because we're using dynamic routes to match client requirements, I'll try to use it and see how I could fit that idea in our case, thanks for the lead!

[Hydhen]

I forgot to mention that in we're mostly using translation for components for now, for pages your example will work, somehow, but for components ready to pick out of the box, what would be the best practice?

[shaharkazaz]

@Hydhen Not sure I follow, it's best of you provide me with a reproduction that mimics your structure and needs.