v4.0.0-next release discussion

[andrii-bodnar]

Share your thoughts and feedback regarding the v4.0.0 version release 🚀

[zvictor]

I just tried it out!

Keep in mind that I am a totally new user and I was not planning on jumping straight into an alpha release, but I simply couldn't make v3 work with typescript locally. Right away I could see that the support for typescript has improved and the errors were gone. 👍

I was quite happy until the moment I integrated it with Crowdin. It seems that as v4 has moved to the hash id idea, Crowdin now reads hashes where it expects to see translation sources (po's msgid).

As result, Crowdin is now giving me hashes to translate 😅

[crazyyi]

I just tried it out!

Keep in mind that I am a totally new user and I was not planning on jumping straight into an alpha release, but I simply couldn't make v3 work with typescript locally. Right away I could see that the support for typescript has improved and the errors were gone. 👍

I was quite happy until the moment I integrated it with Crowdin. It seems that as v4 has moved to the hash id idea, Crowdin now reads hashes where it expects to see translation sources (po's msgid).

As result, Crowdin is now giving me hashes to translate 😅

We are using 3.17 in production with all the typescript support. Maybe you just need to tweak the config a bit more.

[timofei-iatsenko]

What format you use? po file is recomended and works well with crowdin.

[andrii-bodnar]

By default, Crowdin uses the msgid as a source string. In case when this parameter contains a custom id or autogenerated id, we need a custom PO header: "X-Crowdin-SourceKey: msgstr\n" to tell Crowdin where to get source strings during upload.

This is the default behavior, for example, in Poedit 😬

[andrii-bodnar]

I was thinking about the possibility to configure extra PO headers for the extractor, what do you thin about that?

[timofei-iatsenko]

It works well out of the box with po files. No special configuration needed. Just use recommended parameters and avoid json as format for catalogs.

Extractor preserve all headers saved in the catalog, so if you add header "X-Crowdin-SourceKey: msgstr\n" it would stay there.

[rafaelmaiolla]

I tried it today. I was basically looking for the fix for context and that seems to be working fine in v4.

But I found something that looks like an issue.
In the docs, it is said that it is possible to use something like this:

const message = defineMessage({
    id: 'Some ID',
    message: 'Some Message',
    context: 'Some Context',
    comment: 'Some Comment',
});

(...)

<Trans id={message.id} />

But the props for Trans require a children

type TransProps = {
  children: ReactNode
} & CommonProps

So Typescript is complaining about it.

[rafaelmaiolla]

Just to confirm, if I want both comment and context defined, my only option is to use defineMessage, right?

I don't see these props in <Trans component anymore.

[rafaelmaiolla]

Another thing is that the type returned by defineMessage for the id is different from the one that <Trans accepts.

type MessageDescriptor = {
    id?: string;
    comment?: string;
    message?: string;
    values?: Record<string, unknown>;
};

type TransProps = {
    id: string;
    message?: string;
    (...)
};

So it is not possible to use something like <Trans id={color.id}/> as in the example.

[timofei-iatsenko]

Why not? You only need id from MessageDescriptor

[timofei-iatsenko]

Just to confirm, if I want both comment and context defined, my only option is to use defineMessage, right?

There is a Trans in Macro and Trans in @lingui/react, you only need Trans from @lingui/react if you want to define messages somewehere outside of react components and use it later. Trans macro has context and description and message properties

[rafaelmaiolla]

Why not? You only need id from MessageDescriptor

if from MessageDescriptor is of type string | undefined the one in TransProps is string.