Support for Qute Type-safe Message Bundles

[angelozerr]

Support for Qute Type-safe Message Bundles

Fixes #800

[angelozerr]

The support for Qute Type-safe Message Bundles starts working with Java interfaces (but not with properties file).

See the following demo:

@mkouba @FroMage I have started the support for Qute Type-safe Message Bundles which works only with Java interface. I need to support properties file.

Any feedback are welcome if you need some feature.

[angelozerr]

@mkouba I have tried to play with @MessageBundle and I have several questions:

• could we define 2 interfaces wich implements @MessageBundle and the other @MessageBundle("msg1"). I tried it and to write expression like {msg:hello} and {msg1:hello} but it doesnt work.
• according my test, you need to write an interface which implement @MessageBundle even if you wish to use msg:message (with a key). Is it normal? I have this error:

No namespace resolver found for [msg] in expression {msg:message('hello_name',name)}

[angelozerr]

I have improved the support and now you can see message content as inlay hint in the template:

@mkouba @FroMage @fbricon @datho7561 @JessicaJHee for now I display as inlay hint the message but I wonder if it should be better to display the evaluaded message .

For instance:

{msg:hello_name('Lucie')} [Hello Lucie!]

If yes what about when name comes from a variable like

{msg:hello_name(person.name)}

Should we display:

• {msg:hello_name(person.name)} [Hello person.name!]
• or don't evaluate to display {msg:hello_name(person.name)} [Hello {name}!]

[mkouba]

I have improved the support and now you can see message content as inlay hint in the template:

@mkouba @FroMage @fbricon @datho7561 @JessicaJHee for now I display as inlay hint the message but I wonder if it should be better to display the evaluaded message .

For instance:

{msg:hello_name('Lucie')} [Hello Lucie!]

If yes what about when name comes from a variable like

{msg:hello_name(person.name)}

Should we display:

* `{msg:hello_name(person.name)}  [Hello person.name!]`

* or don't evaluate to display `{msg:hello_name(person.name)}  [Hello {name}!]`

I think that we should display the message template and not the evaluaded message. Mainly because we are not always able to evaluate the message template and then it might become confusing... (the {msg:hello_name(person.name)} [Hello person.name!] example).

[angelozerr]

I think that we should display the message template and not the evaluaded message. Mainly because we are not always able to evaluate the message template and then it might become confusing... (the {msg:hello_name(person.name)} [Hello person.name!] example).

Ok thanks for your feedback @mkouba !

[angelozerr]

I need to clean my code and write tests. This PR provides the first support for Qute messages but it need to be improved with:

• support for locale
• support as inlay hint message when it is defined in a msg.properties file.
• code action to create an AppMessages when it doesn't exists.
• support msg:message completion
• other?

I will need that in separate PRs to avoid having a big PR.

@datho7561 @JessicaJHee you can start to play with this PR. Once tests and code will be cleaned I will notice you.

[angelozerr]

To play with Qute messages, I suggest that you use the qute-messages that I will use for Qute JDT tests.

[angelozerr]

Please note that I have encountered 2 bugs in Qute messages support:

• Defining message in msg.properties file doesn't work with default locale quarkusio/quarkus#32354
• Cannot using 2 classes with Qute @MessageBundle with different namespace quarkusio/quarkus#32355

[FroMage]

I think that we should display the message template and not the evaluaded message. Mainly because we are not always able to evaluate the message template and then it might become confusing... (the {msg:hello_name(person.name)} [Hello person.name!] example).

I don't know. I was going to answer the other way, and display the text substituted. At a point (in the view) where we don't know what {name} maps to, because we don't know the name of the parameters, I find it more useful to display Hello Lucie for constants, and Hello {person.name} for non-constant expressions.

[angelozerr]

I don't know. I was going to answer the other way, and display the text substituted. At a point (in the view) where we don't know what {name} maps to, because we don't know the name of the parameters, I find it more useful to display Hello Lucie for constants, and Hello {person.name} for non-constant expressions.

It was my original idea by @mkouba think we should not evaluate the message #845 (comment)

[angelozerr]

@datho7561 @JessicaJHee the PR can be reviewed now, code is clean and tests exists now.

[JessicaJHee]

I played around and looks great! I just noticed some very minor things.

I think this feature you mentioned would be very nice to have in a future PR:

• support as inlay hint message when it is defined in a msg.properties file.

[angelozerr]

I played around and looks great!

Thanks!

I think this feature you mentioned would be very nice to have in a future PR:

It is in my plan, but this PR is already big, so I prefer providing message support in separate PRs to have easier review.

[angelozerr]

@JessicaJHee I have improved inlay hint and now you click on it to edit the Java message by going to the java method.

It requires to improve it to set the location to the @message annotation content and not the Java method but we can do that in a separate PR (if you are interested you could work on it).

Once message properties support will be available #847 my idea is to provide the capability to open the msg.properties file.

[angelozerr]

@datho7561 @JessicaJHee can we merge this PR?

[datho7561]

I haven't had a chance to look at it yet, but I know that Jessica reviewed it. Do you think it's ready to merge, Jessica?