chore: Reference contributor for Hilla translate method usage

[MarcinVaadin]

Fixes #232

[github-actions]

Artifact build on last commit: distributions.zip.
For MacOS users: there is a zip inside this zip and Finder unzips them both at once. Use unzip distributions.zip from Terminal or check solution for Archive Manager.

[mgarciavaadin]

Works for Hilla, good job!
I did not notice any change in Flow though, what should I expect?

[MarcinVaadin]

I did not notice any change in Flow though, what should I expect?

With this update only vaadin-i18n.translations bundle properties are considered. Without that fix if you use getTranslation('server.port') spring application.properties will be opened which was wrong.

[mgarciavaadin]

I did not notice any change in Flow though, what should I expect?

With this update only vaadin-i18n.translations bundle properties are considered. Without that fix if you use getTranslation('server.port') spring application.properties will be opened which was wrong.

Then I understood correctly and it is not working for Flow ;) . At least it still is showing the application properties file as options.

ping @MarcinVaadin

[mgarciavaadin]

In the Flow use case I still see all the application.properties options suggested if I click on a translate("server.port") translation.

[rodolforfq]

Any chance we could include the I18NProvider.translate method in the Flow inspections as well? Would be nice for all 3 different approaches to be equally hi-lighted:

• Component.getTranslation() => already included in VaadinReferenceContributor class (renamed to FlowReferenceContributor on this PR)
• UI.getTranslation() => inherits Component above
• I18NProvider.translate() => doesn't work

I understand you may want to do this in a separate PR, just throwing the idea out there since a customer is interested.

[MarcinVaadin]

Any chance we could include the I18NProvider.translate method in the Flow inspections as well?

Sure!

[MarcinVaadin]

@rodolforfq you meant com.vaadin.flow.i18n.I18NProvider.getTranslation( ) ?

If so, it's interface and implementation might be custom, not only based on properties file...

[rodolforfq]

@MarcinVaadin you are right. In that case, it should be com.vaadin.flow.i18n.DefaultI18NProvider#getTranslation as it is the default implementation and it uses the properties file. If a user creates a custom implementation, it is most likely not going to be based on the properties file and as such, no hi-lightning should be expected either.

[rodolforfq]

I took a second look at this. You can't call the static method on DefaultI18NProvider as you can on the interface. It doesn't make much sense to add this to the plugin after all. The Component#getTraslation method seems to be the most straightforward way to use the localization feature.

While the static method on the I18NProvider interface is very useful for some specific cases (initializing an Enum with localized values, for example), it falls outside the scope of the framework itself. Please disregard my previous comments 🙇🏼‍♂️