Localization

[overheadhunter]

Now that @purejava officially starts developing the first real "plugin" for Cryptomator (see #2), we need to discuss how these are displayed to the user.

For example, in case of keychain access providers, the user sees a dropdown element in Cryptomator's settings to choose between installed providers. At the moment, the display name is retrieved from the localizable strings.properties in the GUI jar, using the fully qualified class name of the implementation as part of the key.

This allows translators to translate the displayed string right within the main project. However, it restricts the use of plugins that we aren't aware of or that are proprietary.

[overheadhunter]

One option would be to add methods that return localized strings when needed. E.g. in case of the keychain access provider, add this:

/**
 * @return Localized name displayed to the user when configuring the keychain.
 */
String getDisplayName();

[infeo]

I would vote for keeping localization of plugins as simple as possible. This might not be the big vision that one day plugins might even provide new GUI views or something similar. But it keeps the bar for developing a plugin low.

On the other hand, real localization is done with a resource bundle. The JDK docs even explicitly describe the use case of a service provider with its own resource bundle, see https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/ResourceBundle.html.

[overheadhunter]

I would vote for keeping localization of plugins as simple as possible.

Yes, but HOW?

As explained above, we can hardly add all localization into the main app. But having it inside the service jar means that translators are unaware of it.

[infeo]

But having it inside the service jar means that translators are unaware of it.

Well, our translators are unaware of it. But this is natural recapping that we are talking about third-party plugins. We cannot say, here is a plugin API, but the translation is controlled by us. The plugin developers need to do that. I can understand the desire to have a seamless user experience, but I don't see this is possible here without taking control over the whole plugin.

Of course there is the possibilty to "mark plugins as officially supported" (or something like this) and provide for those support and infrastructure. For example, always keep an up-to-date fork for such a project in our organization with activated locale creation.

[overheadhunter]

Ok, agreed. I didn't read that clear statement in your previous post.

So basically you too want the plugin to bring its own localization, so the API can rely on localized strings.