robisim74/qwik-speak

In production build it seems like that the translation is lost on route change.

Zankel-Engineering opened this issue · 9 comments

Zankel-Engineering commented

Hi Robi,

might also be an issue on my side. But I don't know where.

Please see attached screenshot after a route change the translation for a json key is always undefined.

image

Do you have an idea. This behaviour only occurs in the prod build.

You can also see it here:

https://1eedbbba.zankel-engineering.pages.dev/

Sebastian

robisim74 commented

Hi Sebastian,

as you can see from your screenshot, the translation in the js chunks has not been inlined.

This happens when the keys are dynamic, for example: ${type}.cta.primary because it is not possible to know the parameter value type during the build: look at the qwik-speak-inline.log file in your root folder after the build.

The dynamic keys must be placed in the runtimeAssets, as explained here.

You can also find a step by step guide in Quick start and Localized routing examples.

Zankel-Engineering commented
Zankel-Engineering commented
robisim74 commented

I'm not sure I understand what I have to tell you. Please can you explain?

Zankel-Engineering commented
robisim74 commented

During the build, Inline plugin transform the t function into string in js chunks, for example:

From:

const t = useTranslate();
const banner = { text: t('home.video.text') };

to:

const banner = { text: `span class="primary">Welcome!</span><br />Find out now why you are in the right place` };

and creates browser chunks one for each language: therefore no runtime lookup, no file loading and better performance.

When you have code like this:

const t = useTranslate();
const { type } = useContext(CompanyContext);
return (
        <h1
            class="xs:text-center sm:text-left xs:text-4xl sm:text-5xl/[4rem]"
            dangerouslySetInnerHTML={t(`${type}.heroSection.headline`)}
         />
    )

which value should be used during the build to transformt(${type}.heroSection.headline) into string? and how would reflection be useful?

Zankel-Engineering commented
Zankel-Engineering commented

Hi Robi I try to extend the qwik-ui package today. I wanted to use this lib here: Link

It could also help with our problem. But it is so fucking old and it is difficult to patch it. I guess I will do the feature for qwik ui without it. There are methods used from typescript that don't exist anymore. Don't want to update that lib.

Maybe we could write something like this one day ourself. But it is to much work for me today.

I wanted to use it in a typeguard, which doesn't make so much sense here anyway. But at least it can be used as a runtime condition:

export function isKeyOfQwikUiAriaAttributes(
  key: string
): key is keyof QwikUiAriaAttributesKebab {
  const ariaAttributeKeys = propertiesOf<QwikUiAriaAttributesKebab>();
  return ariaAttributeKeys.includes(key as keyof QwikUiAriaAttributesKebab);
}

export function isKeyOfAriaAttributes(
  key: string
): key is keyof AriaAttributes {
  const ariaAttributeKeys = propertiesOf<AriaAttributes>();
  return ariaAttributeKeys.includes(key as keyof AriaAttributes);
}

but not for the typing here because of the typecast.

robisim74 commented

The problem with inlining isn't just a types problem: even if a union type were available for the variable, what would the inlining do? write a switch with all possible values and rewrite all translation functions? Really risky to do, especially on code already translated and transformed by the Qwik Optimizer.

I'm closing this issue, to avoid confusion. Please open a separate discussion for suggestions and ideas.