Possible to map between index and source text

[Stadly]

I have a special use case where I, for some customers, need to override a few text strings. I want to have the application localized using wuchale, but be able to, based on the signed in user, override some strings. My plan is to, for each locale, define a mapping from source text to override text on the customer, stored in the database. When loading the catalog, I plan to do something like this:

1. Load the catalogs using wuchale like normally
2. Load the text override map for the current locale from the database based on the signed-in user
3. For each override-text, find the corresponding index in the wuchale catalogs
4. Update the index in the catalog with the override-text

I understand that this will result in the loader having to do async work, and hence placeholders will be shown. I don't think that will be an issue.

The problem I have is how to solve step 3. What do you think about one of these ideas:

1. Implement an option for emitting a map from extracted text to catalog index that can be enabled per adapter in the wuchale config.
2. Expose adapters in the Vite plugin:

export class Wuchale {
    // ...
    get adapters(): ReadonlyMap<string, AdapterHandler> {
        return this.#adapters
    }
}

Then I think I would be able to use a plugin like this:

import { wuchale } from '@wuchale/vite-plugin'

const wuchalePlugin = wuchale()

function wuchaleSourceMapPlugin() {
    return {
        name: 'wuchale-source-map',
        generateBundle() {
            // With the proposed getter, this would work:
            for (const [key, handler] of wuchalePlugin.adapters) {
                const sourceMap = {}
                for (const [sourceStr, id] of handler.sharedState.indexTracker.indices) {
                    sourceMap[id] = sourceStr
                }
                this.emitFile({
                    type: 'asset',
                    fileName: `wuchale-source-map-${key}.json`,
                    source: JSON.stringify(sourceMap),
                })
            }
        },
    }
}

export default {
    plugins: [wuchalePlugin, wuchaleSourceMapPlugin()],
}

[K1DV5]

If I didn't miss anything on what you want to achieve, why don't you just put the logic right before it's used then instead of modifying the catalogs? If you have this:

<div>Hello</div>

Then why not do something like

<div>{signedIn ? txtFromDb : 'Hello'}</div>

Because I'm not sure if i18n should be involved in this, based on what you described. If I'm not missing something.

[Stadly]

One of the selling points of our solutions is that they are very flexible and higly customizable to the customer's needs, including localization specific to the customer's culture and terminology. It is not often that we need to adjust a lot of texts, but at the same time the number of texts that it must be possible to adjust is large.

I could do something like

<div>{welcomeMessage() ?? 'Hello'}</div>

and let welcomeMessage return null if there is no customer-specific localization for that messge. But then I have to manage keys myself, and also text mixed with expressions would be a pain. Not to mention nested structures. I would lose much of the benefits of wuchale.

I don't think I can do something like this:

<div>{localize('Hello')}</div>

Since 'Hello' would be transformed into _w_runtime_(1), and I would lose the key needed for checking if the customer has a localized version of that string.

Maybe I could write my own Vite plugin transforming

<div>{localize('Hello')}</div>

to

<div>{localize(/*@wc-ignore*/'Hello', 'Hello')}</div>

and then I could use the first argument as the key, but still I would miss out on wuchale's ingenioius handling of text mixed with expressions and nested structures.

Do you see any better alternatives?

[Stadly]

After a bit more pondering, I still think i18n is the right tool for the job. The difference is that the catalog is not necessarily known at build-time, and hence the catalog must be dynamic instead of static. When looking at it from that perspective, maybe you see a better option, that may also be useful in other scenarios?

I'm open to contributing on this, if you see a solution that you would want to have in wuchale.

[K1DV5]

After sleeping on it too 😄 I agree, and it can open up other possibilities. And so implementation wise, the best way would be to have wuchale write the sequence alongside the compiled catalogs, so each compiled catalog will have a corresponding "manifest" file. And it should export an array of keys ["Foo", "Bar", ...] because it doesn't make sense to have an object just to convey indices.

What's inside the array would be the uncompiled, extracted message, and context if any (same message may be repeated with different contexts). And if that's the case, you also need the message compiler exported too, to be able to load the modified messages, compile them and replace them inside the compiled catalogs. But we don't want to import the whole of wuchale during runtime, so the compiler should be exported from wuchale/compiler which is just a matter of adding it to package.json because it's already an independent module. That way it's not imported by default, but it's available if you need it.

If you want to work on it, the best place to start would be this function

wuchale/packages/wuchale/src/handler/index.ts

Line 198 in 6974814

#compileForLocale = async (loc: string, hmrVersion = -1) => {

And the manifest should be written next to the compiled catalog.

Thank you for offering to contribute btw.

[Stadly]

Sounds great! Thanks for the pointer - I'll give it a go :) Thanks for the awesome library!

[Stadly]

Seems to work in my simple tests, at least! How does this look? #288