• Hex editor available in German
  • https://github.com/chcg/NPP_HexEdit/tree/master/HexEditor/lang
  • https://github.com/chcg/NPP_HexEdit/tree/master/NativeLang/src/lang
• Multireplace available in Danish, French, German, Hungarian, Italian, Portuguese, Russian, Spanish, Ukrainian
• json tool available in Italian, Arabic, Chinese,French, German, Italian, Japanese, Korean, Twaiwanist
• NppMenuSearch available in German, Italian

• Hex editor available in German
  • https://github.com/chcg/NPP_HexEdit/tree/master/HexEditor/lang
  • https://github.com/chcg/NPP_HexEdit/tree/master/NativeLang/src/lang
• Multireplace available in German, Hungarian, Italian, Russian, Spanish
• json tool, available in Italian (now it is possible to translate it to all Notepad+'s supported languages)

the list of plugin that are working on it:

• https://github.com/NPP-JSONViewer/JSON-Viewer/issues/190

I’ve created a new issue in the GitHub repo asking for plugins to be notified when localization is changed.

The necessary messages and notifications for plugin translation to match NPP has been implemented in this commit, as I requested in that issue.

@PeterJones
I would recommend adding some documentation of this new feature in the user manual.

For what it’s worth, NppCSharpPluginPack now has a working example of how to respond to this new notification, although the code may be a little bit difficult to understand if you’re not a C# programmer.

I finally figured out how to make it so that the UI language of a C# plugin automatically changes to follow Notepad++ when the user changes their preferences, rather than requiring the user to close and reopen Notepad++ to see their new preference reflected in the plugin UI. This was implemented in this commit to NppCSharpPluginPack.

The downside

However, this change would cause a quite noticeable reduction in Notepad++ performance (possibly up to 10% more CPU usage than before) even when the user is not actively using the plugin. For example, this change would make editing and opening files slightly slower, not just using the plugin’s commands.

Given that the user will probably not be changing their UI language very often, and this change would only improve their experience between when they change their UI language and when they close Notepad++, I am not really convinced that it is worth actually implementing this change in any plugins. That said, I’m open to changing my mind.

@conky77
What do you think? Do you think that it is really important that translatable plugins immediately change their language to the Notepad++ UI language?

Thoughts on how the downside could be eliminated

As far as I can see, the whole reason that you have to degrade performance to allow plugins to automatically follow the Notepad++ UI language is that Notepad++ uses an internal message (not broadcast to plugins) to notify that it’s changing its UI language. As a result, my plugin has to create a new NativeWindow that is notified of every single message that Notepad++ receives (not just plugin messages), which is both hacky and leads to the aforementioned performance degradation. By the way, kudos to Peter Frentrup for figuring out how to do this.

It seems to me like the obvious solution is for Notepad++ to broadcast to plugins when it changes its UI language, so that plugins can be notified of this in the normal fashion. I’m thinking about opening a new issue in the NPP Github repo, and I’ll link the issue below if and when I do.

Although the code largely speaks for itself, I will try to provide an outline of how I think daddel80’s framework for translating to other languages works, since his approach is most relevant to C++ plugin developers, who certainly outnumber C# plugin developers.

1. The actual mapping from the native language to other languages is done in the languages.ini file and the language_mapping.cpp source file. Every message in your plugin needs to have a short descriptive name, which is mapped to the English message in language_mapping.cpp and to other languages in languages.ini.
2. All the remaining code for translation seems to be in this region of MultiReplacePanel.cpp. Here are some search results that show how the translation code is referenced elsewhere.

If I understood well, there is also a proposal for making a standard for translations here

You partially understood. Unfortunately, my code can’t really be a general “standard for translations” because plugin authors can’t adopt it unless:

• their plugin is written in C# (most plugins are written in C++)
• they are willing to include the code necessary to parse JSON with comments (JsonTools naturally has that code for obvious reasons).
• they are using Windows Forms to make forms (WPF is more popular IIRC, although this isn’t too big of an issue)

• Hex editor available in German
  • https://github.com/chcg/NPP_HexEdit/tree/master/HexEditor/lang
  • https://github.com/chcg/NPP_HexEdit/tree/master/NativeLang/src/lang
• Multireplace available in German and Russian
• json tool , available in Italian (it gets the Windows languages/cultures, not all Notepad++ languages can be supported)

If I understood well, there is also a proposal for making a standard for translations here

The ability to translate is not built into the various plugin templates, as far as I know, so each plugin author is responsible for implementing translatability on their own. As far as I know, there is no standardization for translations on plugins.

Here is the request for translation of a plugin.

Is it possible to translate any other plugin?

It is possible to translate any plugin where the plugin’s author has already defined a method of translation for that plugin.

The post you linked to was the author of that plugin, who has already implemented the code to allow translations, coming and asking users of that plugin to help by providing the translation text for that plugin; and the link that @Karlo-F listed is another plugin that has the hooks compiled in to allow translation.

But you cannot come into the forum and just ask “could someone translate plugin XYZ for me”, for a random plugin that you use, and expect someone else to be able to translate it for you. If you have a specific plugin that you’d like to see have the hooks to be translatable, you’d have to go to that plugin’s issue-list, and request that the author add in those hooks (assuming the hooks don’t already exist), and then once a version was released that had the ability to accept translations, you or someone else who knows the destination language would have to spend the time to do all the translations for that destination language, verify they work, then submit them to the plugin to be included with future releases.